[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080805142403.GA16529@skywalker>
Date: Tue, 5 Aug 2008 19:54:03 +0530
From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To: Theodore Tso <tytso@....edu>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Problem with delayed allocation
On Tue, Aug 05, 2008 at 09:47:23AM -0400, Theodore Tso wrote:
> On Tue, Aug 05, 2008 at 06:51:33PM +0530, Aneesh Kumar K.V wrote:
> > This should not be needed. I was trying to force the pages to writeback.
> > generic_sync_sb_inodes actually move the inode to s_dirty if the
> > pages_skipped differ after a writeback. But the confusing part is we
> > are not looking at s_dirty list again. We move s_dirty and s_more_io to s_io
> > only once in queue_io
>
> Yes, but ext4_da_writepages() gets called twice in the __fsync_super()
> code path, right? Once with wbc->sync_mode set to WB_SYNC_HOLD, and
> once with wbc->sync_mode set to wbc->sync_mode set to WB_SYNC_ALL,
> corresponding to sync_inodes_sb() getting called twice, once with
> wait=0 and once with wait=1.
>
But we would still can have pages skipped in the second call to
ext4_da_writepages(). But this make me wonder how xfs is doing
delalloc. Also this should be possible in other file systems too. The
delayed allocation logic is just exposing it much easily.
sync_inodes_sb(sb, 0);
generic_sync_sb_inodes
write 10 pages and moves 10 to pages skipped.
move the inode to s_dirty.
sync_inodes_sb(sb, 1);
generic_sync_sb_inodes
move s_dirty to s_io
write 10 pages and move 5 pages to skipped list
move inode to s_dirty.
I guess sync_inodes_sb() should ensure that all dirty pages
are written to the disk. And currently i can see may ways in
which generic_sync_sb_inodes fails to do that. generic_sync_sb_inodes
is suitable for pdflush work function which get called periodically
But for __fsync_super i guess we need a different API which ensures
that all the dirty pages are synced to the disk.
-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
Powered by blists - more mailing lists