Hi ,
there are a lot of other documents for developers i couldn't find the original location, because transarc.com no longer exists , but google helps out :-)
---> http://www.mirrors.wiretapped.net/security/cryptography/filesystems/arla/prog-afs/shadow/progint/
Sven
| Hannes Eriksson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 10/12/05 03:56 PM |
|
(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
> <[EMAIL PROTECTED]> wrote:
>
> >- 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.)
>
> Actually, we already have that layer. OpenAFS doesn't have two
> fileservers; it has one fileserver which can be compiled with any of three
> different backends (inode, namei, and windows). I'd expect work in this
> area to involve writing new fileserver backends, not whole new fileservers.
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
> fileserver.
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...
>From 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
--
main(){double s=0,n=1;for(;n<2<<23;s+=4/n-4/(n+2),n+=4);printf("%f",s);}
/* [EMAIL PROTECTED],cs}.umu.se www.{acc,cs}.umu.se/~hannes ICQ#27865609 *\
\* finger [EMAIL PROTECTED] for my public key */
[attachment "signature.asc" deleted by Sven Oehme/Germany/IBM]
