From owner-freebsd-hackers Wed Oct 3 10:45:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id EB57C37B401; Wed, 3 Oct 2001 10:45:30 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f93HjSs66866; Wed, 3 Oct 2001 10:45:28 -0700 (PDT) (envelope-from dillon) Date: Wed, 3 Oct 2001 10:45:28 -0700 (PDT) From: Matt Dillon Message-Id: <200110031745.f93HjSs66866@earth.backplane.com> To: Zhihui Zhang Cc: Peter Wemm , Ian Dowse , Yevgeniy Aleynikov , ache@FreeBSD.ORG, mckusick@mckusick.com, Ken Pizzini , hackers@FreeBSD.ORG Subject: Re: patch #3 (was Re: bleh. Re: ufs_rename panic) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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