Date: Wed, 3 Oct 2001 10:48:14 -0400 (EDT) From: Zhihui Zhang <zzhang@cs.binghamton.edu> To: Matt Dillon <dillon@earth.backplane.com> Cc: Peter Wemm <peter@wemm.org>, Ian Dowse <iedowse@maths.tcd.ie>, Yevgeniy Aleynikov <eugenea@infospace.com>, ache@FreeBSD.ORG, mckusick@mckusick.com, Ken Pizzini <kenp@infospace.com>, hackers@FreeBSD.ORG Subject: Re: patch #3 (was Re: bleh. Re: ufs_rename panic) Message-ID: <Pine.SOL.4.21.0110031029380.11609-100000@onyx> In-Reply-To: <200110030224.f932OIO62159@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The rename routine is probably the most convoluted in the entire file
system code (FFS). Now that everybody's memory is fresh, I would like to
ask something about it:
(1) I am always wondering why not use a global rename lock so that there
is only one rename operation in progress at any time. This method is
used by GFS and probably Linux. This could make the code simply. Maybe
we can even get rid of the relookup() stuff.
This may reduce concurrency, but rename should not be a frequent
operation.
(2) In the code of 4.3-release, we grab the source inode while holding the
locks of target inodes. In ufs_rename(), we have:
if ((error = vn_lock(fvp, LK_EXCLUSIVE, p)) != 0)
goto abortit;
I wonder whether this could cause deadlock. I think locking more than
one inode should be done in some sequence (ie. order them by inode
number).
(3) Matt says "For example, if you have two hardlinked files residing in
different directories both get renamed simultaniously, one of the
rename()s can fail even though there is no conflict
Can you explain this a little bit more?
(4) This is not related to rename(). But ufs_mknod() reload the inode
through VFS_VGET() to avoid duplicate aliases. I can not see why it
is necessary. I asked this before, but have not got any satisfactory
responses.
Any ideas are welcome. Thanks,
-Zhihui
On Tue, 2 Oct 2001, Matt Dillon wrote:
>
> :
> :Matt Dillon wrote:
> :> Here is the latest patch I have. It appears to completely solve the
> :> problem. I have shims in unionfs and nfs for the moment.
> :
> :This seems rather large compared to Ian Dowse's version.. Are you sure that
> :you're doing this the right way? Adding a whole new locking mechanism
> :when the simple VRENAME flag to be enough seems like a bit of overkill..
>
> Ian's doesn't fix any of the filesystem semantics bugs, it only prevents
> the panic from occuring. For example, if you have two hardlinked files
> residing in different directories both get renamed simultaniously, one
> of the rename()s can fail even though there is no conflict. If you
> have a simultanious rmdir() and rename(), the rename() can return an
> unexpected error code. And so forth.
>
> If you remove the filesystem semantics fixes from my patch you
> essentially get Ian's patch except that I integrated the vnode flag
> in namei/lookup whereas Ian handles it manually in the syscall code.
>
> Also, Ian's patch only effects system calls. It doesn't do the same
> fixes for nfs (server side) or unionfs.
>
> -Matt
>
> :I'm not criticizing your work, I am just wondering if you have considered
> :Ian's work and feel that it is wrong or the wrong direction.. His certainly
> :appears more elegant than yours so I want to understand why you feel yours
> :is better than his.
> :
> :freebsd-hackers
> :Message-id: <200110022152.aa36964@salmon.maths.tcd.ie>
> :
> :Cheers,
> :-Peter
> :--
> :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
> :"All of this is for nothing if we don't go to the stars" - JMS/B5
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.21.0110031029380.11609-100000>