linux-ext4 - Re: Running fsck of huge ext4 partition takes weeks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <EDB725A6-436E-4B98-8EBF-DAB1E4E68FE4@dilger.ca>
Date:	Mon, 31 Aug 2015 21:19:51 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Alexander Afonyashin <a.afonyashin@...net-team.ru>
Cc:	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: Running fsck of huge ext4 partition takes weeks

On Aug 31, 2015, at 1:20 AM, Alexander Afonyashin <a.afonyashin@...net-team.ru> 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@...cue ~ # 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@....edu> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html