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  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 <>
Subject: Strange behavior when attempting to convert a file to extents using chattr

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,
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
I attempted this on an Arch system with both kernels and 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, 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:
for the first attempt at running the command;
for the second try; and
for the final attempt.

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

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

My kernel config, if it is of interest, is at:

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?
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists