Comments on: User Space File Systems http://www.linux-mag.com/id/7814/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: cldavisjr http://www.linux-mag.com/id/7814/#comment-8525 cldavisjr Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7814/#comment-8525 <p>CUSE is an example of extending the FUSE user space file system implementation to control and communication of character device files. All devices in Linux provide their interface through the file system and CUSE has allowed us specific control of USB HID standard input devices that is not possible in the current scheme of USB character device drivers. KUDO\'s for FUSE and CUSE! </p> CUSE is an example of extending the FUSE user space file system implementation to control and communication of character device files. All devices in Linux provide their interface through the file system and CUSE has allowed us specific control of USB HID standard input devices that is not possible in the current scheme of USB character device drivers. KUDO\’s for FUSE and CUSE!

]]> By: kurgbe http://www.linux-mag.com/id/7814/#comment-8526 kurgbe Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7814/#comment-8526 <p>Very interesting article. With FUSE, we are going a little bit towards microkernel OS. Linus did not believe in microkernels (MINIX) and designed a fat OS. Probably at that time with \"slow\" CPU, there was too much overhead to have OS services in the user space. Now machines are becoming enormously fast for a typical usage and the microkernel architecture might be the way forward. This is my opinion, anyway. </p> <p>History might repeat itself: in the 60\'s we had microkernel OS: there was no file system, just a read / write to disk. UNIX (70s, 80s) and PC OS (Windows, Mac, ...) (90s) brought fatness to the OS. Now it is time do go on a diet, otherwise the monsters will explode! </p> Very interesting article. With FUSE, we are going a little bit towards microkernel OS. Linus did not believe in microkernels (MINIX) and designed a fat OS. Probably at that time with \”slow\” CPU, there was too much overhead to have OS services in the user space. Now machines are becoming enormously fast for a typical usage and the microkernel architecture might be the way forward. This is my opinion, anyway.

History might repeat itself: in the 60\’s we had microkernel OS: there was no file system, just a read / write to disk. UNIX (70s, 80s) and PC OS (Windows, Mac, …) (90s) brought fatness to the OS. Now it is time do go on a diet, otherwise the monsters will explode!

]]> By: aotto http://www.linux-mag.com/id/7814/#comment-8527 aotto Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7814/#comment-8527 <p>A rule of thumb that I have used is when your filesystem needs to interact with networked resources (Auth Directories, Remote File Servers, etc.) then use FUSE and work in user space for that. This rule also applies if you want to consume some existing libraries like zlib, pthreads, pcre, expat, etc.</p> <p>If you are only doing things local to the box, and are willing to use only what already exists in the kernel or implement whatever functions you need yourself, then you could do it as a kernel based filesystem, and get a small performance benefit.</p> <p>One thing this article did not mention is that FUSE does not give you a simple facility to implement ACL\'s on your filesystems. As a result, most FUSE systems don\'t implement ACL\'s at all, and that makes them undesirable for multi-user setups. You\'ll end up needing a separate instance of the FUSE client for each user. Yuck. I think ZFS is the most sophisticated of the FUSE based filesystems I\'ve seen, and it does not have ACL\'s implemented.</p> <p>If you are a talented developer, and very interested in FUSE, I suggest making an extension to it to make it bonehead simple to implement ACL\'s within a FUSE filesystem. If we get a standardized way to do ACL\'s and build that right into FUSE we could get some very interesting multi-user solutions from it. </p> A rule of thumb that I have used is when your filesystem needs to interact with networked resources (Auth Directories, Remote File Servers, etc.) then use FUSE and work in user space for that. This rule also applies if you want to consume some existing libraries like zlib, pthreads, pcre, expat, etc.

If you are only doing things local to the box, and are willing to use only what already exists in the kernel or implement whatever functions you need yourself, then you could do it as a kernel based filesystem, and get a small performance benefit.

One thing this article did not mention is that FUSE does not give you a simple facility to implement ACL\’s on your filesystems. As a result, most FUSE systems don\’t implement ACL\’s at all, and that makes them undesirable for multi-user setups. You\’ll end up needing a separate instance of the FUSE client for each user. Yuck. I think ZFS is the most sophisticated of the FUSE based filesystems I\’ve seen, and it does not have ACL\’s implemented.

If you are a talented developer, and very interested in FUSE, I suggest making an extension to it to make it bonehead simple to implement ACL\’s within a FUSE filesystem. If we get a standardized way to do ACL\’s and build that right into FUSE we could get some very interesting multi-user solutions from it.

]]>