From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Problem with delayed allocation
Date: Tue, 5 Aug 2008 19:54:03 +0530 [thread overview]
Message-ID: <20080805142403.GA16529@skywalker> (raw)
In-Reply-To: <20080805134722.GA12544@mit.edu>
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
next prev parent reply other threads:[~2008-08-05 14:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-02 20:07 Problem with delayed allocation Theodore Ts'o
2008-08-02 22:40 ` Theodore Tso
2008-08-04 3:16 ` Aneesh Kumar K.V
2008-08-04 14:08 ` Theodore Tso
2008-08-04 14:52 ` Aneesh Kumar K.V
2008-08-04 15:27 ` Aneesh Kumar K.V
2008-08-04 15:33 ` Aneesh Kumar K.V
2008-08-04 16:35 ` Aneesh Kumar K.V
2008-08-05 6:44 ` Theodore Tso
2008-08-05 6:52 ` Aneesh Kumar K.V
2008-08-05 13:21 ` Aneesh Kumar K.V
2008-08-05 13:47 ` Theodore Tso
2008-08-05 14:24 ` Aneesh Kumar K.V [this message]
2008-08-05 15:16 ` Theodore Tso
2008-08-06 10:05 ` Aneesh Kumar K.V
2008-08-06 10:11 ` Aneesh Kumar K.V
2008-08-07 0:49 ` Mingming Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080805142403.GA16529@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox