[OpenAFS-devel] RE: fsck

[Neulinger, Nathan R.]

I would suggest that the ideal approach would be - support a simple,
possibly slower, approach on ALL systems. Then, you can add the specialized
fsck/etc. as an option on any system that you have enough information to do
it.

I'd imagine that using the reiserfs specific features on linux would
probably result in an extremely fast implementation - particular for some of
the direct open stuff.

-- Nathan

> -----Original Message-----
> From: Default [mailto:aeneous@speakeasy.org]
> Sent: Tuesday, November 07, 2000 6:14 AM
> To: 'openafs-devel@central.org'
> Subject: Re: [OpenAFS-devel] RE: fsck 
> 
> 
> 
> > Because the directory lookup overhead on most UNIX 
> filesystems is quite
> > high.  The result is that a server that accesses its data 
> through links in
> > the filesystem is considerably slower than one that 
> accesses them by inode
> > number.  IIRC, ext2 is better about this than most systems, 
> but it's still
> > not as good as being able to do lookups by number.
> 
> Maintaing references to viceinodes from native fs directories 
> does not require 
> that the fileserver perform open-by-pathname, and I don't 
> believe that the 
> linux server does so.
> 
> > Also, AFS keeps a small amount of metadata with each inode, 
> namely the
> > parent volume, vnode, uniqifier, and data version of the 
> vnode with which
> > that inode is associated.  This information can be of 
> critical importance
> > when reconstructing a volume whose vnode indices were 
> destroyed.  When the
> > through-the-filesystem approach is used, this metadata must 
> be stored in
> > an index file somewhere else in the filesystem (possibly 
> not even on the
> > same disk).  Storing it separately increases the chances 
> that it will be
> > lost, or that the wrong data will be used.
> 
> This is tricky, but it's not insurmountable. No harder than rewriting
> fsck from scratch for several proprietary OSes without filesystem 
> source code.
> 
> 
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
>