[OpenAFS] possibly stupid question: why can't AFS serve "normal" directories like samba/nfs?

[Earl Shannon]

Hello,

I'm not sure why you would be nervous.  A file system is a
file system and stores data the way its designed to. Simply
because you can't see the data in  /vice<whatever> using
an ls command shouldn't make you nervous.  You're not
nervous using a RAID set are you? Data spread out over
all those disks! What were they thinking?

There were design goals in mind when the folks at CMU
started the project. I reckon they felt that attaining those
goals was much easier going the volume route than the way
you suggest.  How would you go about moving an entire
directory from one server to another in a smb or nfs environment?
Yes, I know it can be done, but the ease provided by AFS
is pretty cool.  What about replication? What do you need to
do to provide access to the files on an nfs or smb server
seamlessly in case a server goes down? Granted AFS doesn't
do read write replication (yet).  But there is a lot of
stuff that doesn't require it. Serving applications/binaries being
the biggy. Also, it provided a single file system to present
to our web servers long before anything else did. How would
you allow a campus of thirty thousand plus students to each
have their own web page and make it easy to manage?
( Not that they all set one up, but they can if they want to.)
Part of the real benefit of AFS comes when you start to
have a lot of space to manage.  Quite frankly if you only
have a small number of users to provide space for AFS
may be overkill. Deciding what is small is an exercise left
up to the reader. :)

Yes, there is a somewhat steeper learning curve to using
AFS, particularly when setting it up the first time.  If a
sysadmin doesn't want to take that time to learn it that is
their loss. :(

That said, the project certainly needs to improve its documentation.
It's been a sore point on the list for quite a while now. Sadly
none of us want to or can  pony up to the table to make it happen.
Myself included. Few of us have that time to commit. We are
busy with the learning curves of other stuff. :)  The only book
besides the documentation I am aware of for AFS is
"Managing AFS: The Andrew File System" by Richard Campbell.
And its been out for several years, so I'm not sure how
relevant some of the material would be. But it is at least readable
compared to the regular documentation and gives someone a
place to start their AFS education.

Regards,
Earl Shannon

Adam Megacz wrote:

>It's always made me a bit nervous that AFS keeps the data on the
>server's disk in a nonstandard format, but there must be a good reason
>for this.  Why doesn't the afs server just serve files out of a "plain
>old directory structure" like nfsd, smbd, and the rest?
>
>AFS-specific stuff (acls, locks, etc) could be kept in an extra file
>in each directory (".acl") which isn't served to the client, and if
>the client tries to create a file called ".acl", the server just maps
>that to "..acl" (and "..acl" maps to "...acl", etc).
>
>Would it be feasible to construct an afs server that worked this way?
>
>I'm sure everybody here who's been working with AFS for a long time
>has complete faith in the chunk format used to store server-side
>files, but in terms of adoption, I have to say that this aspect is a
>huge, huge turn-off to most sysadmins who are considering AFS for the
>first time.  That may be irrational, but it's the way a lot of people
>think, and it's been a problem for me when trying to convince people
>to adopt OpenAFS.
>
>  - a
>
>  
>