Date: Wed, 3 Oct 2001 10:45:28 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Zhihui Zhang <zzhang@cs.binghamton.edu> 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: <200110031745.f93HjSs66866@earth.backplane.com> References: <Pine.SOL.4.21.0110031029380.11609-100000@onyx>
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.
Well, you could say that about virtually any filesystem operation.
Bitmaps are shared, for example. It is a bad idea to try to code
simplistic solutions to complex problems. Throughout the code history
of BSDs we have had to constantly make adjustments to algorithms that
were originally not designed to scale past what the authors originally
believed was reasonable.
:(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).
Hmm. Yes, there might possibly be a problem there. We may be
safe due to the fact that only directory scans and rename hold multiple
vnodes locked, and in this case the destination directory holding the
destination file is already locked. However, if the source directory/file
gets ripped out from under rename() the 'new' location of the source
directory/file could cause a deadlock against another process. It
would be very difficult to generate it though.
:(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
I don't know the answer to this at the moment.
-Matt
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?200110031745.f93HjSs66866>