> "Gerard J. Cerchio" wrote:
> >
> > Hi Frankho,
> >
> > 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. 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).
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...
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...
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.
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 ?
FrankH.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
