Re: fixing the vnode lifecycle

[Brett Lymn <brett.lymn%baesystems.com@localhost>]

On Wed, Sep 25, 2013 at 02:33:43PM +0200, J. Hannken-Illjes wrote:
> On Sep 22, 2013, at 5:28 AM, David Holland 
> <dholland-tech%netbsd.org@localhost> wrote:
> 
> <snip>
> > First, obviously the vfs-level vnode cache code should provide vnode
> > lookup so file systems don't need to maintain their own vnode
> > tables. Killing off the fs-level vnode tables not only simplifies the
> > world but also avoids exposing a number of states and operations
> > required only to keep the fs-level table in sync with everything else.
> > This will help a great deal to get rid of the bodgy locking and all
> > the races.
> > 
> > (If any file system does anything fancy with its vnode table, other
> > than iterating it and doing lookups by inode number, I'd like to find
> > out.)
> 
> Expect some file systems to use  a key size != sizeof(ino_t) -- nfs
> for example uses file handles up to 64 bytes.
> 

Right, as do a few other file systems.  IIRC all file systems provide a
filehandle generation routine, the vnodes should be looked up using the
handle not the inode number.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."