There was such a problem, copying files from Windows on a local network, about 1 million files weighing 200GB (in a simple way, with nautilus). After 411242 files (26.6GB) were copied (this is the last attempt), the system hangs and produces some kind of cracks on a black screen, among which you can find sdb1 - this is the screw itself (4TB HDD). It is mounted in / mnt / sdb1 /, fs ext4. Why is this happening? After all, if you copy a little, then everything works fine.

LOGOS dsmeg and syslog: http://rghost.ru/6Mqrjp4PN

  • The question is suspiciously similar to this: ru.stackoverflow.com/questions/430364 - Regent
  • one
    Add, if not difficult, the output of the tail of the dmesg. I see that there are disk errors. Do something like dmesg -T|tail -n 25 and show us. - Ergil Osin
  • @Regent, similar-like. only which one is considered a double? - aleksandr barakin
  • I have no relation to this question. Naryl information that could end the inode. If so, how to track it and how to avoid it? Now I will try the option that was offered above. - sanu0074
  • @alexanderbarakin this question appeared later, so I think you need to consider it as a duplicate. But that is if that question has the right answer. - Regent

1 answer 1

The file system may have run out of inode . You can view the situation on them for all mounted file systems using the df -i command. example output (in the fifth column, the percentage of inodes used):

 $ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/dm-0 920272 207134 713138 23% / udev 497545 440 497105 1% /dev tmpfs 499982 769 499213 1% /run tmpfs 499982 3 499979 1% /dev/shm tmpfs 499982 7 499975 1% /run/lock tmpfs 499982 14 499968 1% /sys/fs/cgroup /dev/sda1 124496 335 124161 1% /boot tmpfs 499982 9 499973 1% /run/user/1000

for a specific file system, you can specify the mount point (the author - / mnt / sdb1):

 $ df -i /mnt/sdb1

or, even if the file system is not mounted, with the command sudo tune2fs -l /dev/sdb1 | grep -i inode sudo tune2fs -l /dev/sdb1 | grep -i inode . example output:

 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Inode count: 920272 Free inodes: 713166 Inodes per group: 8144 Inode blocks per group: 509 First inode: 11 Inode size: 256 Journal inode: 8 First orphan inode: 1863 Journal backup: inode blocks

Pay attention to the inode count and free inodes .

Unfortunately, after creating the ext * file system, it is no longer possible to change the number of inodes in it. It is necessary to re-create the file system (after saving all its contents somewhere), specifying, for example, a different type of use of the file system.

You can set the type with the -T usage-type mkfs.ext4 program.

For a list of types, see /etc/mke2fs.conf .

A very large number of inodes will be created, for example, for the type news (the smaller the inode_ratio , the more the inode will be created, and the file system will be broken up into a larger number of smaller pieces).

but you can, without specifying the type of use, transfer directly to the mkfs.ext4 program the desired inode_ratio using the -i parameter.

for example:

 $ sudo mkfs.ext4 -i 4096 /dev/sdb1

warning : just don’t get carried away with inode_ratio reduction: each inode “selects” several bytes (set using inode_size , which is better not to change) the “useful capacity” for “service” information.

  • one
    look into the future we are not given. the value of inode_ratio determines how small the disk space will be “sliced”: this is the minimum space occupied by the file. even if the file has zero length, at least one inode it “bites off” from the file system anyway. - aleksandr barakin
  • one
    you only gave the ending of the dmesg output. if after the described failure you have not yet rebooted the machine, save all the dmesg output to a file ( dmesg > /tmp/some_file ) and put it somewhere. perhaps there is some hint. - aleksandr barakin
  • one
    If the hangup happens again, then, first of all, you should try to fix the "krakozyabry on a black screen." - aleksandr barakin
  • one
    @ sanu0074, sorry, wrong. There is a hangup moment. Here is Jun 17 12:15:41 server pulseaudio[3630]: last message. The following is Jun 17 19:03:31 server rsyslogd: after a reboot. And before them (except pulseaudio) Jun 17 11:44:30 server dbus[659] , Jun 17 12:06:32 server dhclient and Jun 17 12:09:01 server CRON Only thoughts about the causes of the accident did not add up .. - avp
  • one
    @ sanu0074, firstly, you can accurately determine whether the hang is connected to the network. To do this, copy files / directories locally, without involving a network. secondly, it is better to spend waiting for a hangup by switching to the first virtual terminal ( ctrl+alt+f1 , you can go back to the "chart" somewhere on the 6-8 terminal - ctrl+alt+f6 , etc.) - there is linux may have time to write a “farewell letter”. - aleksandr barakin