Re: Fuse
Re: Fuse
- Subject: Re: Fuse
- From: Andre-John Mas <email@hidden>
- Date: Mon, 21 May 2007 11:03:59 -0400
On 21-May-07, at 10:21 , Amanda Walker wrote:
On May 21, 2007, at 8:05 AM, Dan Shoop wrote:
Production is about maintaining and running operations according
to set service levels using established procedures and methods.
Ad-hoc operations are not established or standard operating methods.
That places the two rather at opposites.
I'm not sure I follow how this relates to FUSE, however.
FUSE is just a well defined API for implementing a file system in a
userspace process rather than in the kernel--it is to file systems
what pseudoterminals (ptys) are to character devices. If anything,
by defining a stable (and OS-independent) API, FUSE is less "ad
hoc" than the methods used for implementing userspace file systems
in userspace in the past (webdav, the automounter, and so on).
Now, this certainly makes it easier to prototype a new file system
implementation than writing a kernel VFS plugin is, but that's
orthogonal to the quality of any given implementation, which is
what matters for whether or not you'd use it in production. And
since a defect in the file system module won't cause a kernel
panic, one could argue that at any given quality level, a userspace
implementation may well be *more* robust than a kernel implementation.
Adding to this:
Quality can only be defined in terms of a set of metrics. If these
metrics are well defined, then whether the driver is kernel-space or
user-space it is immaterial. The basic premise for a good driver is
that is does the job properly without bring down the operating
system. Moving a driver into user space avoids the potential of
bringing down the OS, but still has the basic premise of 'should do
the job properly without crashing'. In fact this basic premise
applies to any piece of operational code, no matter where it is in a
running system.
A read only file system has the requirement that it reads the data on
the disc in such a way that what the rest of the operating
environment sees corresponds to what is on disk. A filesystem that
allows writing to disk has the extra requirement of ensuring that the
data on disk represents what was written and is consistent. Writing a
read only filesystem is much easier to do, since you don't have to
worry about long term data corruption. It is for reasons such as
this, I believe, that the NTFS kernel driver is read only.
While FUSE makes it easier to write a driver, the metrics for quality
control stay the same (especially if your reputation matters). An
extra benefit that I perceive is potentially larger user base and
pool of expertise. What I mean by this last point is that since a
FUSE driver does not require intricate knowledge of the low-levels of
a specific operating system, so we can easily benefit from people
developing filesystem on *BSD and Linux. Also because of the
potentially larger user base you are going to find more people
reporting issues, since in reality some issues only happen in the field.
From my understanding the main advantage of a kernel based driver is
that of performance, but as we saw with the evolution from SCSI based
CD writers to IDE based CD writers, the increasing performance of the
hardware is such that these differences end up being very small,
except for the most extreme of conditions.
Andre
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Fuse (From: Andre-John Mas <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |
| | >Re: Fuse (From: Filipe Cabecinhas <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |
| | >Re: Fuse (From: Uli Kusterer <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |
| | >Re: Fuse (From: Uli Kusterer <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |
| | >Re: Fuse (From: Amanda Walker <email@hidden>) |