All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Jan Kara <jack@suse.cz>, Mingming Cao <cmm@us.ibm.com>,
	tytso@mit.edu, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [RFC PATCH] ext4: Fix the locking with respect to ext3 to ext4 migrate.
Date: Wed, 12 Mar 2008 14:38:11 +0530	[thread overview]
Message-ID: <20080312090811.GA9511@skywalker> (raw)
In-Reply-To: <20080312085629.GR5851@webber.adilger.int>

On Wed, Mar 12, 2008 at 02:56:29AM -0600, Andreas Dilger wrote:
> On Mar 11, 2008  22:28 +0530, Aneesh Kumar K.V wrote:
> > On Tue, Mar 11, 2008 at 04:25:37PM +0100, Jan Kara wrote:
> > >   I agree here. IMHO the better option would be to just build the
> > > extent-tree for converted inode on best-effort basis. If we find in
> > > the end that someone has allocated new block to the file (via mmap
> > > filling a hole) while we are converting, we can just cancel the
> > > conversion. Because I think the cost of extra rwsem (both in terms of
> > > additional memory needed for each inode structure and in time needed for
> > > rwsem acquisitions) is more than I as a user would like to bear given
> > > how rare the conversion is.
> >
> > Something like the below ??
> >
> >  	down_write(&EXT4_I(inode)->i_data_sem);
> > +	/* check for number of blocks */
> > +	if (total_blocks  != inode->i_blocks) {
> > +		retval = -EAGAIN;
> > +		up_write(&EXT4_I(inode)->i_data_sem);
> > +		goto err_out;
> 
> Is this enough, or should we use the inode version instead

We are already holding inode->i_mutex. So the only possible operation is
adding new blocks via mmap write to holes. Also inode version is tricky
because it is available only with i_version mount option. We are also
interested only in new blocks added event.


-aneesh

  reply	other threads:[~2008-03-12  9:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-07 10:53 [RFC PATCH] ext4: Fix the locking with respect to ext3 to ext4 migrate Aneesh Kumar K.V
2008-03-07 11:17 ` Mingming Cao
2008-03-07 11:31   ` Aneesh Kumar K.V
2008-03-07 23:47     ` Andreas Dilger
2008-03-11 15:25       ` Jan Kara
2008-03-11 16:58         ` Aneesh Kumar K.V
2008-03-12  8:56           ` Andreas Dilger
2008-03-12  9:08             ` Aneesh Kumar K.V [this message]
2008-03-12 11:19           ` 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=20080312090811.GA9511@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@sun.com \
    --cc=cmm@us.ibm.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.