[PVFS-developers] faked /etc/mtab entry

[Robert Ross]

On Sun, 22 Oct 2000, James MacKinnon wrote:

> On Sun, 22 Oct 2000, Robert Ross wrote:
> 
> > I've just about gotten the df output working right (it's the statfs() call
> > that has to work).  It will report the total size, the amount used, and an
> > estimate of the amount available (min_free * nr_iods).
> 
> Great!
>  
> > It's nice to see that the mtab entry is about all that is holding us back
> > on the "real mounting" (i.e. having an entry in /etc/fstab, using plain
> > ole mount) front; perhaps we can get that wrapped up soon too.
> 
> /etc/fstab heuristics could be used, but it's mostly for NFS and local, so
> it may not be entirely appropriate to have PVFS in there (too many other
> dependencies and setup required before mount could reasonably deal with
> it).

Hmm.  I see your point, but I think that having it in there with a
"noauto" option would be a good way to make things more understandable for
users.  You're right that it is necessary to get all the daemons up and
running first, but it's not that much different from NFS.

> AFS does the /etc/mtab insertion in it's own code, since there is a lot of
> setup to do (modules, deamons, etc). Perhaps PVFS could just do similarly
> by adding a simple stanza into the mount.pvfs code on successful completion
> of the mount.
> 
> BTW, I might add additionally that with a 'faked' PVFS entry in /etc/mtab,
> a simple unix:
> 
> 	umount /pvfs
> 
> does the dismount just fine and removes the PVFS entry in /etc/mtab
> (one can then stop the pvfsd and rmmod the module without problem.)

Cool.  It doesn't seem like it would be very hard to get mount.pvfs to
create such an entry.  Any other opinions on which way we should go with
this?

> > We'll probably never use UDP, so I wouldn't sweat that :).  It's a good
> > point though, and I hadn't noticed that before.
> 
> UDP in AFS is what makes it robust :-) ( clients may timeout, but don't 
> hang indefinitely). 

Sorry, but I don't buy this argument.  Careful use of select() and/or
threads can get around issues of hangs in TCP code.  And implementing your
own reliable protocol on top of UDP just creates that much more code,
which is just that many more places for bugs to appear.

Additionally, all the reliable UDP protocols I've seen in code I have
looked at (MPICH, LAM-MPI, PVM) have been slower than the TCP
counterparts.

> UDP also allows AFS to be used behind firewalls (our clusters all have 
> regular public network AFS mounts within private IP domains and can see
> the cells in the outside world at Geneva, Italy, Hamburg, etc, as well
> as our own Campus and local physics AFS cells).

I don't buy this either :).  Firewalls can be configured to let TCP
through just as easily as UDP.  There may be policies in effect that limit
the ability to use TCP, but there is nothing about TCP specifically that
would make it inappropriate for use through firewalls.  

Is there some particular characteristic of UDP that you see as beneficial
in the firewalled environment?  Perhaps I'm just missing something;
wouldn't be the first time :)...

Thanks for the info, input, and sparking conversation on this list!

Rob
---
Rob Ross, Mathematics and Computer Science Division, Argonne National Lab