From: Mingming Cao <cmm@us.ibm.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: 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: Fri, 07 Mar 2008 03:17:33 -0800 [thread overview]
Message-ID: <1204888653.3627.37.camel@localhost.localdomain> (raw)
In-Reply-To: <1204887184-9902-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Fri, 2008-03-07 at 16:23 +0530, Aneesh Kumar K.V wrote:
Hi Aneesh,
> static int init_inodecache(void)
> diff --git a/include/linux/ext4_fs_i.h b/include/linux/ext4_fs_i.h
> index d5508d3..96c0b4f 100644
> --- a/include/linux/ext4_fs_i.h
> +++ b/include/linux/ext4_fs_i.h
> @@ -162,6 +162,18 @@ struct ext4_inode_info {
> /* mballoc */
> struct list_head i_prealloc_list;
> spinlock_t i_prealloc_lock;
> +
> + /* When doing migrate we need to ensure that the i_data field
> + * doesn't change. With respect to write and truncate we can ensure
> + * the same by taking inode->i_mutex. But a write to mmap area
> + * mapping holes doesn't take i_mutex since it doesn't change the
> + * i_size. We also can't take i_data_sem because we would like to
> + * extend/restart the journal and locking order prevents us from
> + * restarting journal within i_data_sem.
How about we start a journal with estimated worse case transaction
credits and then take the i_data_sem down? So that we could ensure that
whenever the i_data_sem is hold, the i_data is protected. That is what
currently DIO does, I think. It would be nice to avoid introducing
another semaphore to protect i_data for migration if we could.
> This will be taken in
> + * page_mkwrite in the read mode and migrate will take it in the
> + * write mode.
> + */
> + struct rw_semaphore i_migrate_sem;
> };
>
> #endif /* _LINUX_EXT4_FS_I */
Mingming
next prev parent reply other threads:[~2008-03-07 11:18 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 [this message]
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
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=1204888653.3627.37.camel@localhost.localdomain \
--to=cmm@us.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--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.