Date: Wed, 31 Mar 1999 15:57:48 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Doug Rabson <dfr@nlsystems.com>, 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: <199903312357.PAA22770@salsa.gv.tsc.tdk.com> In-Reply-To: Doug Rabson <dfr@nlsystems.com> "Re: Panic in FFS/4.0 as of yesterday" (Feb 23, 8:54am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 23, 8:54am, Doug Rabson wrote: } Subject: Re: Panic in FFS/4.0 as of yesterday } 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? ROFL. Look at how long it's taken me to just respond to this question. The only real downside of making this change that I am aware of is that you won't be able to rename mount points. That might be a feature, though, since renaming mount points causes the mount table to become out of sync with reality. Something else that would greatly help the lock cascade problem and likely help performance under normal circumstances would be to implement shared locks, and only use exclusive locks when something needs to be changed. When doing a pathname lookup, only the final vnode (if it was found) and it's parent directory (if LOCKPARENT was set) would be exclusively locked. The lookup would only use shared locks on the other directories that were traversed. In most cases this would prevent the lock cascade, but the cascade could still happen, probably under artificial circumstances. This change would also allow concurrent lookups in the same directory, which should help performance when multiple processes are active. I suspect this change would not be trivial to implement ... 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?199903312357.PAA22770>