On Aug 31, 2015, at 1:20 AM, Alexander Afonyashin <a.afonyashin@xxxxxxxxxxxxxx> wrote: > > Hi, > > Running fsck from e2fsprogs-1.42.13 results in SIGKILL: > > Inode 4425496 is too big. Truncate? yes > > Block #524289 (103743230) causes directory to be too big. CLEARED. > Block #524290 (3236857350) causes directory to be too big. CLEARED. > Block #524291 (3625464338) causes directory to be too big. CLEARED. > Block #524292 (1370882069) causes directory to be too big. CLEARED. > Block #524293 (3868016883) causes directory to be too big. CLEARED. > Block #524294 (3919147116) causes directory to be too big. CLEARED. > Block #524295 (279419478) causes directory to be too big. CLEARED. > Block #524296 (194746972) causes directory to be too big. CLEARED. > Block #524297 (1695856868) causes directory to be too big. CLEARED. > Block #524298 (587425254) causes directory to be too big. CLEARED. > Block #524299 (142614537) causes directory to be too big. CLEARED. > Too many illegal blocks in inode 4425496. > Clear inode? yes > > Inode 4425357 has compression flag set on filesystem without > compression support. Clear? yes > > Warning... fsck.ext4 for device /dev/sda3 exited with signal 9. > root@rescue ~ # e2fsprogs-1.42.13/build/misc/fsck -v -y /dev/sda3 Hmm, the "fsck" command is just a wrapper, and it is not necessarily calling the e2fsck command from your build tree. You should run: e2fsprogs-1.42.13/build/e2fsck/e2fsck -fy /dev/sda3 That said, if you are having problems with the e2fsck, could you run it under gdb to see where it is failing? Signal 9 is SIGKILL which means that the process was killed by some external signal? > Regards, > Alexander > > On Fri, Aug 28, 2015 at 8:53 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: >> If dumpe2fs is hanging as well, it's likely that the problem may be at >> the hardware level. You might want to check dmesg or the kernel log >> to see if there are any I/O errors being reported from hard drive. >> What might be happening is that when a program (such as e2fsck or >> dumpe2fs) tries to read from a specific part of the hard drive, the >> hard drive is retrying a large number of times because the hard drive >> head or platter surface has gotten damaged in some way. >> >> It might also be a good idea to check the S.M.A.R.T. status using the >> smartctl program. >> >> Cheers, >> >> - Ted Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
