public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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

  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