[OpenAFS-devel] Fileserver as Masters Thesis

[Hannes Eriksson]

--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

(Yes, I'm the "colleague" Niklas mentioned)

On Tue, Sep 27, 2005 at 01:12:20PM -0400, Jeffrey Hutzelman wrote:
> On Monday, September 19, 2005 06:31:54 PM +0200 Frank Bagehorn=20
> <FBA@zurich.ibm.com> wrote:
>=20
> >- Or you create a virtual layer for the existing fileservers, so that you
> >would have a well-defined interface to whatever lies below. (NAMEI or
> >INODE or DB or whatever comes to peoples mind.)
>=20
> Actually, we already have that layer.  OpenAFS doesn't have two=20
> fileservers; it has one fileserver which can be compiled with any of thre=
e=20
> different backends (inode, namei, and windows).  I'd expect work in this=
=20
> area to involve writing new fileserver backends, not whole new fileserver=
s.

I've tried to find that layer for some time now, without success.
I cannot find all the code I'd wish in cvs. There is src/vol/ntops.[ch]
for the windows backend and similar code in src/vol/namei_ops.[ch] but I
have a hard time finding corresponding functionality for the inode
backend. Additionally, there seems to be related code in src/libafs/,
but something tells me that code is client side...

The fscm-ispec.pdf is about the other end of the fileserver, so that
isn't very useful. I haven't found any other dev docs in the CVS or on
the net mentioning the fileserver.

It would be most helpful if someone could give me some rough pointers as
to which parts of the source tree are related to what backend.

> These tools [hostafs tafssrv] are interesting, but they're not the basis =
for a full-service=20
> fileserver.=20

I will check them out, especially tafssrv, for the ideas it might give,
but I really want to make something that at least I would like to use...

=46rom the mail discussions and books I've read, a useful fileserver
backend would probably:

*) Be stable by not keeping references to inodes separate from the
   underlying fs (stray inodes make fsck on /vicep? a bad idea, right?)
*) Be reasonably portable without #ifdef or a large number of platform
   specific files (to platforms I can test on, i.e. linux 2.4/2.6, aix
   5.1, sol9/10)
*) Be (or having serious potential at becoming) fast, possibly by
   by-passing existing fs naming layers
*) Not be limited by historic data types for file sizes or number of
   files (other than what RX or the fileserver frontend imposes).

This list makes me think that a good design would start by not trying to
live on top of a pre-existing file system. Of course this would mean
having to implement a fsck and salvage, but they might be combined into
one tool...

/Hannes

--=20
main(){double s=3D0,n=3D1;for(;n<2<<23;s+=3D4/n-4/(n+2),n+=3D4);printf("%f"=
,s);}
/* hannes@{acc,cs}.umu.se  www.{acc,cs}.umu.se/~hannes  ICQ#27865609  *\
\*         finger hannes@finger.acc.umu.se for my public key          */

--envbJBWh7q8WU6mo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDTRX52V7Dd4hASOURAuC8AJ4t7MJFYDfImwIuvWstUTDApm81owCdHcUk
6q0PSM5EVi+L8aeHFVmaep0=
=bWhW
-----END PGP SIGNATURE-----

--envbJBWh7q8WU6mo--