Date: Tue, 23 Feb 1999 08:54:14 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Terry Lambert <tlambert@primenet.com>, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <Pine.BSF.4.05.9902230851380.60339-100000@herring.nlsystems.com> In-Reply-To: <199902221428.GAA28942@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Feb 1999, Don Lewis wrote: > On Feb 20, 10:52pm, Terry Lambert wrote: > } Subject: Re: Panic in FFS/4.0 as of yesterday > > } > If it works, then changing lookup to not require locks on both vnodes at > } > the same time would be a good thing. One of the reasons that NFS doesn't > } > have proper node locks is that a dead NFS server can lead to a hung > } > machine though a lock cascade from the NFS mount point. > > I suggested doing something like this, but only at mount points, which > should be sufficient to fix the NFS problem. The only race conditions > that would open would be for things you probably don't want to do > at mountpoints anyway. It sounds as if it might work. Are you interested in coding this? > > } The correct way to do this, IMO, is a back-off/retry, which would > } unlock the lock and queue the operation for retry, which would > } reacquire the lock. > > Wouldn't you have to relock the parent before unlocking the lock (nasty > because it reverses the locking order and might cause a deadlock). If you have a locking protocol like the one we have at present with a pair of locks moving along the pathname, always with the parent and child locked, then you must always lock in the same order to avoid deadlock. If you need to unlock the parent, then you must unlock the child first etc. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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.BSF.4.05.9902230851380.60339-100000>