Brad's Blog

I rember reading about FUSE (Filesystem in Userspace) a while ago and thinking it was a pretty groovy idea without having any particular need for it at the time.

Essentially, FUSE brings filesystem implementation to the masses - where 'the masses' in this case are developers who haven't yet leaped into kernel development. With lots of language bindings available FUSE also makes filesystem development somewhat less painful - where I'm defining pain in this case as the fun and games of c development. :).

I started thinking about FUSE again just the other day when I noticed that ubuntu is now mounting NTFS volumes read/write using NTFS-3G (a FUSE-based driver).

As FUSE becomes more popular this opens up lots of interesting possibilities - support has been added for MacOS and FreeBSD and it sounds like there may be one or two ms windows versions in the works. If this were to happen we might finally have a nice way to mount useful filesystems under ms windows (FAT32 retirement being well overdue, and now somewhat necessary given that DVD images and other large files wont fit).

What's tickling my fancy at the moment:

• Something steganogrpahic. There's already plenty of serious implementations of this but it feels like a meaty enough problem to be interesting to implement. Probabaly something simple like storing the data in images or music or some such thing.
• Slightly sillier - and with little to no useful application - I think it could be fun to give the old pick-a-path/choose-your-own-adventure style text-game a filesystem interface.
• Given my recent developments with Amazon S3 it could also be fun to look at a filesystem view. Given that transferring massive blobs of data back and forth isn't very reliable this could be quite interesting as files would need to be chopped up inside the S3 storage but appear as single entries in the filesystem.

Final comments - I thought I'd start out with a cute little filesystem which was infinitely deep, containing random entries (thus avoiding the time-consuming part of defining a sensible traversible structure). The first thing to strike me is that exceptions vanish without a trace (somewhere in the internals of FUSE/Kernel space).

I'm finding it valuable to wrap FUSE methods in exception catching (logging all errors to a file) - something like:

1    def readdir(self, path, offset):
2      try:
3        self.log('readdir(%s)' % path)
4        for r in  '.', '..', str(random.randint(1,1000)):
5          yield fuse.Direntry(r)
6      except Exception, e:
7        self.log('!!!EXCEPTION THROWN!!! %s' % e)
8        raise e

This way pesky little exceptions are at least identifiable which makes fixing them a bit easier!

Comment by: Bradley Dean at Wed, 23 Apr 2008 18:03:55 (BST)

Szaka (lead developer of NTFS-3G) left a comment (below). I should perhaps clarify my earlier statement to say the FUSE is also extremely useful for developers who do work at the kernel level but have now got a low coding cost alternative!

Comment by: Szaka (ntfs-3g.org) at Wed, 23 Apr 2008 14:06:50 +0300 (EEST)

> Essentially, FUSE brings filesystem implementation to the masses - where 
> 'the masses' in this case are developers who haven't yet leaped into 
> kernel development. 

While this is definitely true, exactly the opposite happened with NTFS-3G. 
We always developed the NTFS kernel driver but the breakthrough came when 
we moved to FUSE. 

Of of the explanations is that NTFS is really huge. The Microsoft NTFS 
river is over 500,000 source lines we must be compatible with. It's almost 
more than all the 60+ in-kernel file systems altogether(!!).

Since the kernel/VFS is rapidly changing we had to spend most of our time 
adapting the huge NTFS code base and supporting backward compatibility. 

The popular Linux in-kernel file systems are sponsored by several big 
companies and many developers work on it as their main job. But NTFS 
weren't sponsored, only very few of us worked on it in our spare time. 
So, the time is __extremely__ critical for us (huge amount of, hard work 
must be done highly efficiently).

FUSE is small and let us isolate from the kernel, so we can fully focus on 
NTFS (which is not entire true because there are several related kernel 
reliability and performance issues being worked on which affects also other 
subsystems and user space application).

Kernel experience helps to write efficient FUSE file system but we try to 
make FUSE perform the best out of box.  FUSE is new and rapidly keeps 
improving.

Regards,
	    Szaka
--
NTFS-3G:  http://ntfs-3g.org

Something I haven't had the 'opportunity' to experience before (given that I've always used US layout keyboards before)...

While using an application on my UK laptop the keymap started to intermittently switch to a US layout - most notable this mean that characters like [" @ #] were in the wrong place. Not helpful while programming...

This was only happening in some applications - the rest continued to use the correct keymap. Huzzah for finding new an unusual microsoft arsenic-laced easter eggs...

The quick'n'dirty solution is to make sure that there is only one keymap available (not great if you are plugging different keyboards into the computer, but hey...):

1. Navigate to Start - Control Panel - Regional and Language Options
2. Select the Languages tab.
3. Press the Details... button.
4. In the Installed services box scroll the the US block and press the Remove button.
5. Press the OK button.

The fix is immediate (surprisingly it didn't need a reboot).