linux-ext4 - Re: Reg: logical volume file system is getting corrupted after multiple reboots.

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 May 2018 14:10:10 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     RAJESH DASARI <raajeshdasari@...il.com>
Cc:     Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: Reg: logical volume file system is getting corrupted after
 multiple reboots.

On May 2, 2018, at 10:26 AM, RAJESH DASARI <raajeshdasari@...il.com> wrote:
> On Tue, May 1, 2018 at 6:15 PM, Eric Sandeen <esandeen@...hat.com> wrote:
>> On 4/30/18 1:27 PM, RAJESH DASARI wrote:
>>> Hi ,
>>> 
>>> We are noticing an issue with logical volume file system is getting
>>> corrupted after restarting the machine for multiple times.
>> 
>> When you say restarting, are you talking about clean reboots, or
>> power fails etc that may replay the log?
> 
> It is clean reboot. no power failures.
> 
>> (Also note that for a while at least on Fedora, systemd was preventing
>> the root filesystem from unmounting cleanly on reboot.)
>> 
>> So, were these log-replay-inducing machine restarts or "clean" reboots?
>> 
>>> This issue we have started noticing after upgrading the kernel to 4.4.121.
>> 
>> What was the previous kernel that did not seem to exhibit the problem?
> 
> we have upgraded from 4.4.106 to 4.4.121 and e2fsprogs from 1.43.9 to
> 1.44.0. After the upgrade this issue is noticed.
> 
> Now I have downgraded the kernel to 4.4.106 and downgraded e2fsprogs
> to 1.43.9 and issue is disappeared.

If that is the case, please try the newer kernel and e2fsprogs independently to isolate which one introduced the problem.  Next, do a git-bisect on the relevant code to isolate it to a specific patch.

Cheers, Andreas

>> If this happens again, capturing the primary super in some way (i.e.
>> e2image, or even simply using dd to copy it) might be interesting, to see
>> exactly what the corruption is.
>> 
> I tried capturing the primary super block using dd command to some
> file, but still i get the same error when i do dumpe2fs on the file.
>> -Eric
>> 
>>> while running tune2fs -c 1 /dev/VG_NEW/state to set the
>>> mmax_mounts_count we are noticing the error.
>>> 
>>> tune2fs -c 1 /dev/VG_NEW/state
>>> tune2fs 1.44.0 (7-Mar-2018)
>>> tune2fs: The ext2 superblock is corrupt while trying to open /dev/VG_NEW/state
>>> Couldn't find valid filesystem superblock.
>>> 
>>> lvs command output is below (there are other logical volumes and
>>> volume groups also along with state volume, I have not pasted them to
>>> minimize this post).
>>> Important thing to note here is always state volume only is getting
>>> corrupted and no file system corruption seen on other logical volumes.
>> 


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)