linux-ext4 - Re: Problem with delayed allocation

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]

Message-ID: <20080804031652.GA11278@skywalker>
Date:	Mon, 4 Aug 2008 08:46:52 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
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.

-aneesh

--
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