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  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:	Mon, 4 Aug 2008 08:46:52 +0530
From:	"Aneesh Kumar K.V" <>
To:	"Theodore Ts'o" <>
Subject: Re: Problem with delayed allocation

On Sat, Aug 02, 2008 at 04:07:19PM -0400, Theodore Ts'o wrote:
> Apparently __fsync_super(), which is called right before remounting a
> filesystem read-only, isn't working correctly.  To reproduce, create a
> script which does this:
> #!/bin/sh
> DEVICE=/dev/closure/test
> mke2fs -t ext4dev /dev/closure/test
> mount $DEVICE /mnt
> cd /mnt
> tar xfj /var/tmp/linux-2.6.26.tar.gz  <----- or some really big file
> du -s
> cd ..
> mount -o remount,ro /mnt
> sync
> dmesg > /tmp/dmesg.out  <----- note all of the ext4_da_writepages error messages
> umount /mnt
> du -s /mnt
> sync
> mount $DEVICE /mnt
> du -s /mnt    <---  note that size of the unpacked hierarcy is much smaller
> This doesn't happen if the ext4 filesystem is mounted with nodelalloc,
> so I assume the problem is in ext4_da_writepages().
> Aneesh, can you look at this?  I've tried going through the code paths
> starting with __fsync_super(), going down through __sync_single_inode(),
> and I can't see anything obvious.
> I've checked and we've had this problem for a while.  I don't think this
> is a recent regression.  The "sync" command does seem to force file data
> out, but it looks like we're not properly waiting for writes to complete
> before __fsync_super() returns.  There is a call filemap_fdatawait() in
> __sync_single_inode(), but it's apparently not doing the right thing.
> Aneesh, can you try to find whatever it is that I missed?  Thanks!!

__fsync_super use filemap_fdatawait(mapping) for waiting on writeback
pages. But all the dirty pages of the inode are not in writeback because
we might have had block allocation failures. Also with the current code
base I am seeing buffer_heads which are unmapped, non delay and dirty
That means writepages won't allocate block for them and writepage cannot
write them.


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