From: Jan Kara <jack@suse.cz>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Mingming Cao <cmm@us.ibm.com>, linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: ext4_page_mkwrite and delalloc
Date: Mon, 16 Jun 2008 19:34:34 +0200 [thread overview]
Message-ID: <20080616173434.GE3279@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20080616160906.GB14214@skywalker>
> On Mon, Jun 16, 2008 at 04:11:41PM +0200, Jan Kara wrote:
> > Hi Aneesh,
> >
> > On Thu 12-06-08 23:44:07, Aneesh Kumar K.V wrote:
> > > With delalloc we should not do writepage in ext4_page_mkwrite. The idea
> > > with delalloc is to delay the block allocation and make sure we allocate
> > > chunks of blocks together at writepages. So i guess we should update
> > > ext4_page_mkwrite to use write_begin and write_end instead of writepage.
> > > Taking i_alloc_sem should protect against parallel truncate and the page
> > > lock should protect against parallel write_begin/write_end.
> > >
> > > How about the patch below ?
> > In principle the patch looks fine, I would only like to see two things
> > checked:
> > 1) Did you do some stress testing of the patch - combining mmapped writes
> > with ordinary writes to the same file and truncation so that we detect
> > possible bugs in locking / data corruption due to some bad locking. This
> > significantly changes when write_begin / write_end can be called in ext4
> > (i.e., it is now called without i_mutex - BTW: that is probably worth a
> > comment before these functions).
> > 2) How does this change influence CPU load for mmapped accesses - I worry
> > about write_begin / write_end path being significantly heavier than just
> > calling writepage. Probably just mmap a large file, write single byte
> > to every page and measure using oprofile whether accumulated time spent in
> > page_mkwrite didn't change to much.
> >
>
> We can actually get away with page_mkwrite if we agree that SIGBUS on
> ENOSPC is not the right way. We can implement writepages for different
> data mode, and allocate blocks in writepages. With those changes we don't
> allocate blocks for mmap area maping holes upon write. Instead we
> allocate block during writepages. Since we can start a transaction
> during writepages we should be ok with respect to new locking.?
Yes, but this has the disadvantage that with this solution you are
unable to free memory by writeback under memory pressure in some cases
(at that path we are not called via writepages()). It may or may not
matter, I'm not sure.
I personally prefer returning SIGBUS on ENOSPC for ext4 (for ext2/ext3
I tend to agree with Andrew that we probably shouldn't change the
behavior).
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
prev parent reply other threads:[~2008-06-16 17:34 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
2008-06-16 14:11 ` Jan Kara
2008-06-16 16:09 ` Aneesh Kumar K.V
2008-06-16 17:34 ` Jan Kara [this message]
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=20080616173434.GE3279@atrey.karlin.mff.cuni.cz \
--to=jack@suse.cz \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--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