Miklos Szeredi provided patches against the 2.6.10 Linux kernel [story] for FUSE, "Filesystem In Userspace". Aptly named, "FUSE exports the filesystem functionality to userspace. The communication interface is designed to be simple, efficient, secure and able to support most of the usual filesystem semantics."
Originally developed for the AVFS project, FUSE has since been utilized by a growing list of userland filesystems. Some interesting examples include the FunFS network filesystem aiming "to be better than NFS", the EncFS encrypted filesytem, the Python-based GmailFS which turns a gmail account into a storage medium, the Phonebook filesystem offering "Deniable Encryption technology", and the Wayback versioning filesystem. The aim is to get the FUSE kernel module merged into the mainline Linux kernel.
From: Miklos Szeredi [email blocked] To: akpm, [email blocked] Subject: [PATCH 0/11] FUSE - Filesystem in Userspace Date: Mon, 10 Jan 2005 19:53:59 +0100 Andrew, Linus, Please apply the following patches, which add Filesystem in Userspace to the kernel. The patches are against 2.6.10. FUSE [1] exports the filesystem functionality to userspace. The communication interface is designed to be simple, efficient, secure and able to support most of the usual filesystem semantics. It can be used for prototyping and for network/virtual filesystems requiring external libraries or programs. A typical example is sshfs [2] which uses the sftp protocol and allows zero-setup mounting of remote sites. FUSE is currently in use by dozens of publicly available filesystems [3], and by many in-house applications. It has proved useful and stable for lots of users. Thanks to everyone for the comments on the last submission. Changes since then are: - Made it Deadlock Free (TM). This includes removing support for shared writable mapping and making all requests interruptible. - Removed INVALIDATE userspace initiated request, this is probably not used by any application. - Updated ABI to be independent of sizeof(long), so dual-size archs don't cause problems - Remove /sys/fs/fuse/version. Version checking is now done through the fuse device The patch is split up to the following parts: 01 - MAINTAINERS, Kconfig and Makefile changes 02 - FUSE core 03 - FUSE device functions 04 - read-only operations (getattr, readlink, readdir, ...) 05 - read-write operations (setattr, mkdir, symlink, ...) 06 - file operations (open, read, write, ...) 07 - mount options controlling the behavior of the filesystem 08 - extended attribute operations (getxattr, setxattr, ...) 09 - readpages operation 10 - NFS export support 11 - direct I/O support Thanks, Miklos [1] http://fuse.sourceforge.net/ [2] http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=140425 [3] http://fuse.sourceforge.net/filesystems.html
Useful. Finally something li
Useful.
Finally something like Plan9's ftpfs becomes possible for Linux in
a more-or-less standard way.
Actually a kernel module that
Actually a kernel module that allows to use ftp as a filesystem has been around for a long time.
ps. just correcting you there, FUSE is a really great stuff...
Actually FUSE is not at all l
Actually FUSE is not at all like Plan 9; but this is much more like it:
http://v9fs.sourceforge.net/
v9fs is what you want
FUSE is not at all like Plan 9; but this is much more like it:
http://v9fs.sourceforge.net/
Skeptical
I'm not sure I buy into this userspace filesystem concept. It looks like most of the referenced FUSE filesystems are toys or proof-of-concept type things.
Anybody have any real information on the overhead associated with FUSE? What about stability? What happens when a FUSE network filesystem has connectivity problems? How slow would a reimplementation of ext2 be through FUSE?
One example use of kernel filesystems (ext2, ...) in FUSE
FUSE has its uses, although reimplementing ext2 for the root filesystem isn't one of them. The speed will be lower without any gains, so the actual speed doesn't really matter.
However, there is a case for normal, in-kernel filesystems to be ported / glued to FUSE:
- when the filesystem may contain random, uncontrolled data. Most filesystems are not robust against random data.
- when the underlying block device may become unavailable while being mounted. The kernel doesn't like that at all.
- when speed is not the (main) issue.
...which holds for removable media like USB keys, floppies and CDs.
So I started playing trying to compile the linux/kernel/fs/* on its own, and got some way through it. It consists of stubbing out a lot of functions, and connecting kernel functions to its libc equivalents.
FUSE for psuedo file systems
Would FUSE be the best way for me to create a psuedo file system (like proc or sys) for fs based control of an embedded system (e.g. a robot)?
I'd say so
Most likely - easier to debug, etc... Yeah, I'd have to say that would be a fairly nice way to control a robot, in fact - easier than coming up with a protocol to shove over a network - just export the directory :) New functionality is also a doddle to export...
Been done
Ever since I saw Inferno (http://www.vitanuova.com/inferno/) I thought it would be cool if Linux could do this stuff.
The executive summary is that Inferno supports per-process, userland file systems and Good Things (TM) happen as a result. Making something like the remote controlled robot is a typical application.
TIM
FUSE has _many_ limitations c
FUSE has _many_ limitations compared with 9p; for example is nowhere near network transparent. I have posted this before, but if you like Inferno or Plan 9 what you really want is v9fs; which I hope will be sent for admission to LKML in the very near future(ie., weeks).
FUSE is production ready code. v9fs looks half done.
I just browsed through the v9fs CVS code, documentation, and forums. It doesn't really give the impression of being ready for prime time. I have written virtual filesystems for FUSE, and LUFS before that, and while FUSE may not implement or be designed for all of v9fs's promises, it is production ready and can handle real-world loads.
I'd say there is room for both. But v9fs has a ways to go in the documentation and examples department for a start. I converted over a virtual filesystem I wrote to use FUSE in a day. Writing a simple test filesystem in FUSE for the first time was less then 30 minutes. None of the examples in v9fs are useful starting points for a virtual filesystem, and the documentation consists mostly of placeholder type stuff. In effect, even an experienced virtual filesystem writer doesn't know what use this thing is. And then on top of that, the examples state they would have to be run as root or SUID.. not compelling..
9p has been used in productio
9p has been used in production for over 15 years: http://plan9.bell-labs.com/plan9dist/
You're playing name games. I
You're playing name games. I talked about v9fs. According to the v9fs forums, it has only recently been able to run bonnie++ without problems.
That's like if someone asked if Linux 0.12 was stable and responding that Unix had been in use for decades.. That's great and all, but if v9fs is being put forth as an alternative to FUSE, then I'm interested in v9fs's state, not some other implementation.
In a protocol it's the design
In a protocol it's the design that matters; the implementation is secondary.
And anyway the history of v9fs goes back at least seven years, and has been used in some of the biggest clusters at LANL for a long time; it just hasn't got much publicity.
The version that just passed bonnie++ is the unstable rewrite for linux 2.6.
No, implementation is not sec
No, implementation is not secondary. Implementation wins battles, design wins wars. If code is going to put into a production system then its implementation must carry its weight. That doesn't mean that a good design can't win, it means only that a good design needs a good implementation to win. Its called being reasonable.
Yes it is
I think the point is that if you have a bad implementation, you can improve it over time and eventually come up with a good implementation, without breaking code along the way. Bad implementation is a temporary failure. Bad design, on the other hand, cannot be solved by recoding. In fact, the only way to fix bad design is to scrap the entire project and start again from scratch.
Linux already supports per-pr
Linux already supports per-process mounts so I would assume you could use those with FUSE to get per-process mounts of userland filesystems.
Does it?
Can you point me to some docs about per-process mounts in linux, please?
try to look at /proc/self/mou
try to look at /proc/self/mounts
See man clone(2). CLONE_
See man clone(2).
FUSE for psuedo file systems
RTA, based on FUSE, may be what you are looking for. Disclaimer: i did not use it in any way :)
http://www.runtimeaccess.com/
What's the API for implementi
What's the API for implementing filesystems in FUSE like? Does it match the kernel VFS API or is it different?
You know, the manual is a good place to find out...
The project page is here... You could always download it and find out.
like translator ?
This look like translator from hurd ?
Interesting uses
Speaking of the Hurd, here's a list of interesting uses that could be enabled by userspace file systems.
KIO Support
With FUSE you can use all of your KIO modules like
smb://
sftp://
fish:// (filebrowsing over ssh-shell access)
webdav://
ftp://
[...]
with non-KDE programs.
KIO-FUSE Homepage
KIO-FUSE can be found in the CVS Module kdenonbeta/fuse_kio
Phonebook
The Phonebook link is to http://kerneltrap.org/ ??
Just a hack
A hack to allow Hurd-like feature in Linux. Hurd allows implementing in user-space and running by unprivileged users many more system services, not just filesystems. (no flames please) Microkernels are the way to go.
(no flames please) KDE is way
(no flames please) KDE is way better than GNOME.
Ummm...
You will find that Plan9 introduced this feature first... As for microkernels being the way to go, you gain very little given that Linux is in many ways very microkernel like - not in terms of processes, but general seperation of things (noticed these things called modules? They can even start up their own (ring 0/1) processes, but that doesn't make a microkernel either). It is, however, very well organised and is certainly quite scalable. What actually makes a microkernel is that device drivers (for instance) run at reduced level of privs, meaning that it is possible for one to have a bug (SIGSEGV equiv) without giving rise to a panic. Note, however, that you will find that the filesystem daemon crashing will probably look very much like your box crashing anyway, so the value of this feature is dubious... Besides, we all know that Linux has no bugs :)
nice
Now how about a userspace block device interface, so you could have something like Daemon Tools that emulates a physical CD drive with a raw CD image, in userspace?
mount -t iso9660 file.iso /mn
mount -t iso9660 file.iso /mnt/wherever
does the same thing.. daemontools is completely unnecessary in linux..
Ofcourse, the "-o loop" optio
Ofcourse, the "-o loop" option should also be used.
mount -o loop -t iso9660 file.iso /mnt/wherever
That is not useful when the f
That is not useful when the file is not an ISO-9660 image, as is the case with raw images dumped with cdrdao (or almost every existant MS windows application.. the classic bin/cue is the most common example).
Which is completely irrelevan
Which is completely irrelevant to the discussion...
Besides there's several ways to convert those to ISO-9660...
Sure
Convert them to ISO-9660 and lose the music tracks, copy protection, etc. That's the point of a block device emulation, to emulate the physical CD (2352-bytes per sector) instead of just mounting the ISO filesystem (2048-bytes per sector, omission of ECC/subchannel on data tracks which causes copy protection not to work, no audio tracks).
I stand corrected... (Crap! ;
I stand corrected... (Crap! ;)
Is it possible to write a raw
Is it possible to write a raw CD ripper (bin/cue) in Linux? After all cdrecord can work, which uses the scsi generic interface with scsi but I don't know how it does atapi).
It's called cdrdao
It's called cdrdao
nbd
The network block device (nbd) lets you implement a block device in userspace. Don't let the network fool you, you can pass it a unix domain socket and use a local process. It's probably not up to the task of emulating a physical CD drive however.
Last I heard it worked fine,
Last I heard it worked fine, except for local mounts, so I'd check if it really works or not first. :-)
Mounting locally does indeed
Mounting locally does indeed deadlock but only in read-write mode. There's a paragraph at the end of the README for nbd userspace tools describing this.
For read-only mode it works well enough that you can mount a CD image from HTTP with this: http://patraulea.com/nbd-http/
Cheers.
Sound drivers in userspace
I'm waiting for the day when Linux moves its sound drivers to userspace.
Windows 2k and up moved the sound drivers to userspace, so now it is the opposite from the free Unixen which have sound in the kernel but video in userspace.
Mike
Waiting for realtime support
Well, on lwn.net I read sometimes ideas about moving a lot of drivers to userspace, and for instance it has been done in 2.6 for USB scanners and such (moved to libusb). The idea is to reduce the number of kernel bugs, since (like Linus said about drivers) "crap is crap".
But for audio, this is difficult, because even with the current situation you can get high latencies... until when Linux does not support hard real-time (actually the situation is not that much better inside the kernel, at least currently - the Ingo's patches of some time ago probably improved the situation).
And yes, Windows NT is more real-time than Linux, at least for what I read (just random readings).
More real-time? Which means w
More real-time? Which means what?
That an application has more processing time, or that an application can get the processor back at a more precise time?
What is real time to you?
It means extremely low latenc
It means extremely low latency so that you can do mixes and edits in real time.
In fact the most important as
In fact the most important aspect of real time isn't how low the latency is, but how predictable it is...
There are free realtime kerne
There are free realtime kernels, if you need that.
Try Shark/HARTIK.
Or RTEMS.
UNIX and realtime in the same sentence is an oximoron i think.
For a kernel to be realtime, processes have to have priorities.
If they enter a syscall, the syscall needs to inherit the priority.
Why?
The sound drivers have to bang on the hardware by definition. Putting this in userspace is wrong from a security architecture perspective and would lead to poor latency. Most of Linux audio besides the drivers is in userspace already, look at ALSA libs and JACK for example.
Putting this in userspace
Strange, whenever someone mentions putting the gfx drivers in kernel, the "gods" reply : Yes, but that would make them slower ! ( due to context switches, read "higher latency" ).
xerces8