On Tue, Aug 05, 2014 at 10:51:53AM -0500, Andrew Deason wrote:
> > Does FUSE provide a suitable counterpart to the pioctl?
> 
> It should be possible to implement pioctls using ioctls or xattrs (both
> of which FUSE supports, iirc). If I were to ever spend more time on the
> openafs FUSE implementation, that is the route I assumed I would take to
> get pioctl support. (I think I talked a little about this during some

This sounds good. I have possibly a too pessimistic view on pioctls
and on FUSE.

> presentation; I can find a link if anyone wants.)

Yes I would be interested to read if you have a link at hand.

> Representing them as xattrs I think has other benefits, too, even
> without FUSE, since it becomes a lot easier to read/write them from
> tools that are aware of xattrs but are not aware of AFS or Coda or
> anything like that, if you expose them as xattrs on the actual relevant

An ultimate solution would be to make the most common userspace tools
applicable (e.g. by implementing pioctls as a virtual file system like
Jan suggested, to be able to fully reimplement cfs as a shell script using
nothing more than cat, printf, rm, cp, mv, touch)

Oh well, if I may dream we could even make repair work like that

ls <conflict>/.codactl/replicas/
diff <conflict>/.codactl/replicas/{server1,server2}
diff <conflict>/.codactl/replicas/server1 <conflict>/.codactl/local
echo server2 > <conflict>/.codactl/prefer

Which could possibly be worth to be available even if <conflict> is not a
conflict but a healthy file or directory, just in case, like "cfs expand".

As of xattrs, their use would exclude OSs which do not support them
(may there are none nowadays ? keeping the dependencies limited is
anyway generally useful)

> files. But I seem to recall there may be some obstacles in that
> approach; and I never got to actually trying to implement it, so there
> might be other issues I never even thought of :)

Thanks for sharing your insight Andrew!

Rune