From: Martin PLACEK <mplac@cs...> - 2005-06-19 09:18:05
> Message: 4
> To: eolson@...
> CC: fuse-devel@...
> Subject: Re: [fuse-devel] Fuse + socket = fuse/nfs?
> From: Miklos Szeredi <miklos@...>
> Date: Sat, 18 Jun 2005 23:14:25 +0200
> > Has anyone done the obvious thing and slapped a TCP socket between the
> > libfuse interface and a fuse "pass-through" file system,
yes, its work in progress for me! I'm doing it as part of my
Masters by Research. The status atm is it supports as you say
a "pass-through" file system, but I'd like it do a bit more than that,
stuff like replication and aggregation of storage, plus more...
I'm treating the project as a learning process at the moment, the code
isn't too bad, but I'd like to get it to state that I'm happy with
before considering releasing it out just yet.
> > so that you can
> > mount a remote file system? i.e., send all the fuse fn calls over the
> > socket. This could be a compelling alternative to NFS, but providing an
> > opportunity to make a couple simple improvements (secure authentication
> > and transport encryption come to mind!)
> > Would this work?
> Well, if the server and client have the same endiannes, then yes.
> Otherwise you'd have some trouble with swapping byte order on every
very true, atm, I'm assuming same endiannes, and I'd imagine structs like
statfs would change even between platforms aswell eg SunOS vs Linux vs... even
differing version of the same OS they would change. (hint: look at the C
source for 'df' command) so you can't just pass those structs around either. So
for the moment I'll have to assume no only same endianess but same version of
OS. I wonder how the file i/o structs will change in nature with 64bit
> > What sorts of performance issues would occur?
With no caching, which is what I've got at the moment the
performance is so.. so.. . Its just gets bad when you do a `ls -l` in a
dir of hundreds of files as it has to do a GETATTR for every single file and
it all happens synchronously so that is a bit painfull, caching that sort
of stuff will help heaps I'd imagine. I found increasing the block
size to help tremendously with perfomance, network latency is a killer when
your shifting around many small blocks synchronously....
> > Would adding flock to the fuse API largely address locking concerns, or
> > is more mechanism needed?
> I'm not sure it's possible to do proper locking in userspace. Does
> the userspace NFS server support file locking?
I'm not too sure what to do about consistency and how it would work with fuse,
for the moment the plan would be to do the locking on the server end. Start of
at file level (lock on opens/unlock on close) than possibly attempt to do it at
block level.. But I'm not really an expert here so if anyone can give me any
pointers here I'd really appreciate it!
Oh and before I forget:
Thanks Miklos for writing such a great piece of software.. all the best!