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-next>] [day] [month] [year] [list]
Message-ID: <20110410003954.4108b9c9@natsu>
Date:	Sun, 10 Apr 2011 00:39:54 +0600
From:	Roman Mamedov <rm@...anrm.ru>
To:	linux-ext4@...r.kernel.org, linux-raid@...r.kernel.org
Subject: tune2fs can't be used on a mounted ext4, or...?

Hello,

Here's what happened. I reshaped my RAID5 to a RAID6 and a larger disk count.
Then I ran "resize2fs /dev/md0". It successfully enlarged the filesystem
online (that took a couple of hours, I think).

Since my count of disks changed, I thought I should change the array stripe
width. Then, while still not unmounting the filesystem, I did:

  tune2fs -E stripe_width=48 /dev/md0

Then I started copying files from another array to the one on which the above
operations were conducted. I did:

  cp -Rp /mnt/array1/data/* /mnt/array2/new-data/

This completed successfully. No errors on the console, silence in dmesg.

Then I thought I'd verify the destination, just to be sure. Luckily, I have
checksums stored in almost every directory as .SFV files (created with "cfv").

And some checksums did not match. On a closer investigation, it appears like
some files deep down in the directory tree (and with a rare occurence,
something like one file in a thousand) were truncated during copying. E.g.
they'd have size of 188 MB instead of 349 MB, or 128 MB instead of 170 MB.
Some files (originally less than 1 MB in size) just had zero-length on the
destination.

Other than these truncations, there is NO corruption of data inside any of the
files. Which kinda rules out CRC-style errors in controller/disk/cable.

So.. this is completely puzzling to me, and I suspect either a kernel bug, or
my mistake, and tune2fs cannot modify a mounted FS (however it did NOT show any
warning that the FS was mounted, and if this is the case, it should've
absolutely refused to operate on a mounted FS).

Any ideas? :)

-- 
With respect,
Roman

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ