[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Panic in FFS/4.0 as of yesterday
From:       Don Lewis <Don.Lewis () tsc ! tdk ! com>
Date:       1999-03-31 23:57:48
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]