[OpenAFS] (no subject)

[Nathan Neulinger]

On Wed, 2002-12-11 at 18:47, Ryan Underwood wrote:
> hi,
> 
> Nathan:
> 
> > The client cache works JUST FINE on journalling file systems. It is
> > solely reiserfs that it has a problem with because you cannot retrieve a
> > file from an inode number.
> 
> You are correct with ext3 since only the metadata is journalled by default.
> However, I was under the impression that problems arose when the actual filesystem
> data is journaled.  Yes, I run ReiserFS on vice partitions and it works fine,
> if a little on the slow side.
> 
> XFS or ReiserFS crashes the kernel on Linux if you try to start the client
> with cache pointing to them.  I haven't tried JFS.

Good point. I don't know on that... 


> > > a file on AFS, nor can I mkfifo.  I'm sure this is obvious to those more
> > they wouldn't be portable if you could.
> 
> Hm, that's true; what about hiding special nodes from non-unix systems? ;)

major 31 minor 0 on HPUX is one of the systems disk drives

major 31 minor 0 on Linux is an interface to the MPU401 midi encoder on
soundblaster audio cards.

Sure wouldn't be too good if you gave all users write access to the
sound card on one system, and unintentionally gave users access to the
contents of the drive on an HP.

Now, that shouldn't be an issue for a unix socket, or fifo. Those would
be relatively safe to allow creation of, and should be portable to any
platform that supports the concept of a fifo or named pipe. Biggest
problem though is whether or not you can create a new file type in AFS
without causing problems with all existing clients. 


> (re: fifos)
> > you want a producer/consumer construct? it would be doable "easily" if you
> > didn't care about more than one consumer, i think. once you have more than
> > one consumer it gets ugly.
> 
> good question.  I can see hypothetical uses where you could use a single fifo
> in AFS space to flag and/or pass data to 1000 slave boxes at once or something
> similar.  However, even being able to run a fifo'ed program in AFS space
> would be neat, and obviously the only workable solution if a multicast fifo
> would be ugly.

Fifo's are purely local. Even on NFS. The idea of having networked fifos
is just plain scary. 


> > > 4) A lightweight, easily portable client.
> > arla? i don't know what you mean, exactly.
> 
> I think maybe I meant a client that can be fully contained within a kernel
> module, for boot discs and the such.  You know, without megs of userland
> support.  Unless that's possible with OpenAFS?

Only user required user space code is afsd, and that's pretty small, and
could probably be compacted down quite a bit if you got rid of all the
configurability.


> > something to be understood. when you clone a volume, for backup or
> > release, or when the server is restarting, this happens.

> Hrm, but what if I'm not doing anything related to the machine at the time?
> 

Has nothing to do with the machine you're on. It has to do with what is
happening with the volume on the file server. I'd suggest vos e to find
where the volume is, and 'vos status' on the server in question if you
see a persistent busy volume message.


> > > I would prefer if that new directory by default would retain the ACL
> > > of the directory above it, instead of being set to system:administrators
> 
> > it should do that, inside a volume. across-volume, no, and doing so is
> > hard, because you can mount volumes as many times as you want, and you
> > don't specify one at creation time. copy acl from what?
> 
> Ah-ha, that might just be the key.  If the ACLs aren't copied across volumes
> then that is most likely the mistake I am making when managing the cell.
> 

Just use "fs copyacl dir1 dir2".

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216