[osol-discuss] FUSE on Solaris

[Roland Mainz]

Frank Hofmann - Solaris Sustaining wrote:
> > "Gerard J. Cerchio" wrote:
> > > Has there been any progress or discussion porting FUSE to Solaris?
> >
> > Well, first I'd like to see FUSE revamped a little bit. Last time I
> > checked (note: My knowledge is almost a year old so I could be wrong) it
> > was very difficult to write FUSE servers in languages which do not
> > support threading (e.g. |fuse_main()| is extremly difficult to integrate
> > into the main event loop of existing, single-threaded applications) or
> > implementing disconnect/recommect of the server without rendering the
> > whole mounted file system invalid. Also missing was locking, record
> > locking, mmap() and ACL support (which would be required to create full
> > NTFS, SMB and NFS support on top of FUSE) and support for controlling
> > the inode-numbering from the application even - which is very important
> > for getting FUSE filesystems exported via NFS (e.g. without inode
> > numbers which remain valid across reboots of the server (e.g. FUSE
> > server restart or whole operating system restart) it's hard to get FUSE
> > filesystems exported without blowing-up all NFS clients when the server
> > restarts).
> 
> All true on that. The biggest issue you mention is the incomplete
> mmap(), since that's core filesystem functionality.

Well, it could be - like other functionality emulated via a shared
library or within the FUSE kernel module if the application does not
provide an implementation. However the API should be there, 1) for
completeness and 2) to avoid that we end-up with an incomplete API which
cannot be changed afterwards since we have to be binary compatible
(Linux people do not care about this - Solaris engineers likely end up
on a pyre when they break something like that).

> It'll be missed
> even if you have no desire to share application data locally (needs
> file locking), or remotely (all mentioned involved NFS issues).

This is not only NFS - it's about implementing the full Unix filesystem
semantics correctly. If the filesystem can be exported via NFSv3
properly (even with reboots/server restarts) then almost everything is
OK.

> But if all you want is to access media-from-whatever-strange-source
> to copy data to/from it, what could be better ?
> 
> While the FUSE architecture ("filesystem services provider daemon",
> if you like) makes it tempting to think about using it for everything,
> keep in mind that e.g. for providing local backing fs for NFS means
> wire -> kernel NFS -> faults -> kernel FUSE -> daemon -> FUSE service ->
> syscalls -> other kernel I/O services -> FUSE service -> daemon ->
> kernel FUSE -> kernel NFS -> wire ... which is a long path, copying
> data around between kernel and userland, and within userland, several
> times. Compared to optimized in-kernel filesystems, there is some
> considerable overhead; UNIX isn't a message-passing-tuned microkernel.
> OSI networking stayed mostly in the heads of designers. The real
> world and the craftsmen devising the actual implementation found
> out it doesn't quite fit...

I am aware about the performance problem and all it's ugly sideeffects -
I've been working on CODA/PODFUK for a while and performance wasn't
always perfect. Another issue not handled by FUSE is security - for
example what will happen if we allow an oridinary user (e.g. set special
group or ACL on the FUSE device entry) to create his filesystem deamon
which generates files with setuid/setgid (there is always the "mount"
option to ignore such bits - but the problem should IMO be handled at
FUSE API level) or other special stuff (for example: devices, pipes,
fifos, doors etc.) ... ?

> My personal opinion on FUSE is that it's most useful for the
> client side. I.e. allow a machine that runs FUSE and services
> providing access to FTP-as-a-filesystem, SCP-as-a-filesystem,
> transparent file encryption, or in order to access 3rd-party
> filesystems (NTFS, Apple HFS, BSD UFS, all heads of the Linux
> fs hydra, ...). And you'll never have to worry about such
> strange things as limitations on how much memory you can have
> for what purposes, why you cannot use all those wonderful
> facilities of the C++ STL or even the C stdlib, you don't
> have to give an arm and a leg for the understanding how to
> initiate I/O to devices or the network from within the kernel.
> The fact alone that you couldn't crash your kernel if your
> FUSE fs service crashed would make it so much easier to write
> filesystems for Solaris that you couldn't balance the scales
> with gold...

I agree with that...

> Never mind that you definitely will not be able to write a
> Solaris kernel-based filesystem driver in Parrot any time
> soon :)

:-)

> > ... beyond these complains it would be very nice to have FUSE in
> > Solaris... :-)
> 
> See above. There's no such thing as perfection, except if you
> see it as the very thing you're working on - all the time :)
> 
> To answer on that question: I've had a short internal assessment
> with one of the managers in engineering about technical feasibility
> of porting FUSE, and a very rough estimate on how much time+effort
> it'd take.
> There is a BSD port of FUSE, which is a simpler starting point
> than the Linux FUSE sources, both due to more closer-related
> kernel interfaces in BSD/Solaris vs. Linux/Solaris and due to
> the license. My estimate is three months to get that code
> running on Solaris if you're working it alone. And then start
> testing/debugging it (its a work in progress), and start
> porting the fs services (given that these are written for Linux,
> portability will s*ck and they'll be full of Linux/gcc-specifics),
> resp. write new ones.

It may be a nice idea to work together with both BSD and Linux people to
create a FUSEv2 which deals with most of the issues listed above (incl.
that it should be possible to export such filesystems via NFSv3 and/or
implement even special stuff such as pipes on top of FUSEv2) ... this
shouldn't be too difficult...

> Check the BSD FUSE port:
> 
>         http://fuse4bsd.creo.hu/
> 
> It'd make a great OpenSolaris project. But to my knowledge
> no work has started yet. At least not within Sun. Any interest ?

Yes... I am very interested once I've hooked-up some
ksh93/libshell/libcmd/libdll/libast build scripts for ON (which is
currently blocked by various unrelated stuff from real life...) ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)