linux-ext4 - Strange behavior when attempting to convert a file to extents using chattr

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]

Date:	Thu, 28 Apr 2011 16:14:59 -0400
From:	Peter Uchno <peter.uchno@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: Strange behavior when attempting to convert a file to extents using chattr

Hello,
I recently converted an ext3 filesystem to ext4 in the hopes of
performance increases. However, I ran into a snag:

In theory, chattr can be used to convert a file to extents using
"chattr +e foo". However, on my system (Archlinux, kernel 2.6.37.4),
the behavior of this command is unexpected. Given a file baz created
when the filesystem was still ext3 (and thus not using extents),
"chattr +e baz" returns zero but "lsattr baz" reveals the file is not
using extents. Run "chattr +e baz" a second time, the same thing
happens. A third time, however, it comes back with:
    "chattr: Input/output error while setting flags on baz"
and an error in the kernel log:
    attempt to access beyond end of device
    loop1: rw=0, want=204802, limit=204800
The file is still not using extents and remounting the filesystem
doesn't seem to change much. Running e2fsck on the filesystem after
unmounting it comes back with some errors. Letting it fix them and
then mounting the FS up again shows that the file is now using
extents.
I attempted this on an Arch system with both kernels 2.6.37.4 and
2.6.38.4 and was able to recreate it by creating a small loopback
filesystem using dd, making a few files on it, converting the FS to
ext4 using "tune2fs -O extents,uninit_bg,dir_index /tmp/fs.ext; e2fsck
-fDC0 /tmp/fs.ext", and then mounting it again as ext4 and attempting
the conversion to extents with chattr. However, on a debian system
with kernel 2.6.32.5, it works as intended (chattr +e bar; lsattr bar
reveals the file converted to extents). I ran strace on the chattr
command on the Arch system and came up with the following:

http://pastebin.com/EpwhLF3t
for the first attempt at running the command;
http://pastebin.com/qB7DiDgF
for the second try; and
http://pastebin.com/jjAdPtBr
for the final attempt.

After doing so, running e2fsck on the filesystem revealed the following:

http://pastebin.com/83q60Wik

And after mounting the filesystem again, the file is now using extents.

My kernel config, if it is of interest, is at:
http://pastebin.com/uk1Hs53P

I'm using e2fsprogs 1.41.14. The Debian system (where it works
normally) has e2fsprogs 1.41.12.

I'm not sure what would cause the filesystem to behave in this
fashion. Does anyone have any insights?
Regards,
Peter
--
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