From: Wendy Cheng <wcheng@redhat.com>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] prune_icache_sb
Date: Mon, 04 Dec 2006 15:46:33 -0500 [thread overview]
Message-ID: <45748929.20406@redhat.com> (raw)
In-Reply-To: <45745207.4030107@thebarn.com>
Russell Cattelan wrote:
> Wendy Cheng wrote:
>
>> Linux kernel, particularly the VFS layer, is starting to show signs
>> of inadequacy as the software components built upon it keep growing.
>> I have doubts that it can keep up and handle this complexity with a
>> development policy like you just described (filesystem is a dumb
>> layer ?). Aren't these DIO_xxx_LOCKING flags inside
>> __blockdev_direct_IO() a perfect example why trying to do too many
>> things inside vfs layer for so many filesystems is a bad idea ? By
>> the way, since we're on this subject, could we discuss a little bit
>> about vfs rename call (or I can start another new discussion thread) ?
>>
>> Note that linux do_rename() starts with the usual lookup logic,
>> followed by "lock_rename", then a final round of dentry lookup, and
>> finally comes to filesystem's i_op->rename call. Since lock_rename()
>> only calls for vfs layer locks that are local to this particular
>> machine, for a cluster filesystem, there exists a huge window between
>> the final lookup and filesystem's i_op->rename calls such that the
>> file could get deleted from another node before fs can do anything
>> about it. Is it possible that we could get a new function pointer
>> (lock_rename) in inode_operations structure so a cluster filesystem
>> can do proper locking ?
>
> It looks like the ocfs2 guys have the similar problem?
>
> http://ftp.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/ocfs2_git_patches/ocfs2-upstream-linus-20060924/0009-PATCH-Allow-file-systems-to-manually-d_move-inside-of-rename.txt
>
>
>
Thanks for the pointer. Same as ocfs2, under current VFS code, both
GFS1/2 also need FS_ODD_RENAME flag for the rename problem - got an ugly
~200 line draft patch ready for GFS1 (and am looking into GFS2 at this
moment). The issue here is, for GFS, if vfs lock_rename() can call us,
this complication can be greatly reduced. Will start another thread to
see whether the wish can be granted.
-- Wendy
prev parent reply other threads:[~2006-12-04 20:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-22 21:35 [PATCH] prune_icache_sb Wendy Cheng
2006-11-22 23:36 ` Andrew Morton
2006-11-27 23:52 ` Wendy Cheng
2006-11-28 0:52 ` Andrew Morton
2006-11-28 21:41 ` Wendy Cheng
2006-11-29 0:21 ` Andrew Morton
2006-11-29 6:02 ` Wendy Cheng
2006-11-30 16:05 ` Wendy Cheng
2006-11-30 19:31 ` Nate Diller
2006-12-01 21:23 ` Andrew Morton
2006-12-03 17:49 ` Wendy Cheng
2006-12-03 20:47 ` Andrew Morton
2006-12-04 5:57 ` Wendy Cheng
2006-12-04 6:28 ` Andrew Morton
2006-12-04 16:41 ` [PATCH] SLAB : use a multiply instead of a divide in obj_to_index() Eric Dumazet
2006-12-04 16:55 ` Christoph Lameter
2006-12-04 18:18 ` Eric Dumazet
2006-12-04 19:49 ` Andrew Morton
2006-12-04 19:55 ` Christoph Lameter
2006-12-04 21:34 ` Eric Dumazet
2006-12-04 21:56 ` David Miller
2006-12-04 22:45 ` Eric Dumazet
2006-12-05 14:42 ` Pavel Machek
2006-12-04 16:51 ` [PATCH] prune_icache_sb Russell Cattelan
2006-12-04 20:46 ` Wendy Cheng [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=45748929.20406@redhat.com \
--to=wcheng@redhat.com \
--cc=akpm@osdl.org \
--cc=cattelan@thebarn.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 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.