From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Mingming <cmm@us.ibm.com>
Cc: Jan Kara <jack@suse.cz>, linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: ext4_page_mkwrite and delalloc
Date: Sat, 14 Jun 2008 12:13:47 +0530 [thread overview]
Message-ID: <20080614064347.GB11866@skywalker> (raw)
In-Reply-To: <1213396521.27507.7.camel@BVR-FS.beaverton.ibm.com>
On Fri, Jun 13, 2008 at 03:35:21PM -0700, Mingming wrote:
> >
> > Since we are not doing any real copy here I guess we can say that
> > we don't do short write. The flag means that.
> >
> > #define AOP_FLAG_UNINTERRUPTIBLE 0x0001 /* will not do a short write */
> >
> > > > + if (ret < 0)
> > > > + goto out_unlock;
> > > > + ret = mapping->a_ops->write_end(file, mapping, page_offset(page),
> > > > + len, len, page, NULL);
> > >
> > > I am still puzzled why we need to mark the page dirty in write_end here.
> > > Thought only do block reservation in write_begin is enough, we haven't
> > > write anything yet...
> >
> >
> > The reason is to get the ordered and journaled mode behavior correct.
> > We need ensure that the meta-data that got allocated in the write_begin
> > get commited in the right order.
>
> I am confused here, I thought this patch is to take advantage of delayed
> allocation, so that we could just call the write_begin in mkwrite, there
> is only block reservation, but no real block allocation and meta-data
> changes? Thus no need to worry about the ordering?
>
The changes are update to ext4_page_mkwrite. This call back is used when
we try to write to page. With nodelalloc and ordered mode we need to
make sure we allocate blocks in ext4_page_mkwrite. Because we can't
allocate blocks in writepage with nodelalloc. So we use write_begin and
write_end. This will ensure that we use block reservation in case of
delayed allocation and do block allocation in case of nodelalloc.
Earlier it used writepage always. That would not work with delayed
allocation. Hence the changes.
> > We need add the buffer_heads
> > corresponding to the data (page) to the right list in the journal.
> > write_end mostly does that.
> >
> I probably missed the basic here, I was assuming the patch also based on
> the new orderd mode? But with the new ordered mode, this part(using
> buffer heads) is replaced with the journal inode list, and with delayed
> allocation, the code to ensure the ordering is pushed later at
> writepages() time.
>
-aneesh
next prev parent reply other threads:[~2008-06-14 6:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 18:14 ext4_page_mkwrite and delalloc Aneesh Kumar K.V
2008-06-12 21:00 ` Mingming Cao
2008-06-13 3:20 ` Aneesh Kumar K.V
2008-06-13 22:35 ` Mingming
2008-06-14 6:43 ` Aneesh Kumar K.V [this message]
2008-06-16 14:11 ` Jan Kara
2008-06-16 16:09 ` Aneesh Kumar K.V
2008-06-16 17:34 ` Jan Kara
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=20080614064347.GB11866@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
/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