OSNews

Since it's a fuse-driver, it will never be merged in the kernel (But maybe parts of it?).

I think you're misunderstanding something. FUSE is short for "Filesystems in USErspace." FUSE itself is in the kernel (available as a module), but it exports a simplified VFS interface to userspace. Filesystems developed for FUSE are not linked into the kernel image, do not run in the kernel address space, and don't import any symbols from the kernel (besides the system call table). So it will never be merged into the kernel, because this doesn't make sense.

There has been some talk on LKML concerning moving some userspace code into the kernel source tree in order to keep them synchronized with the kernel. This is mainly for daemons that rely heavily on sysfs, which is not nearly as stable across kernel releases as is the system call interface. The discussion revolved around udev. Basically (if this were to go down), when you make install a new kernel, it would install the corresponding version of udev. The FUSE daemon does use sysfs for control operations (including aborting out of deadlocks, which can't be fatal if we're allowing userspace filesystems), but this is a very limited and stable interface.

It will be your Linux distributor's responsibility to package the userspace FUSE components and any FUSE filesystems you might wish to use. One excellent example is sshfs. Once you experience its awesomeness, you'll wonder why they even bother with NFS anymore (for the record, there's still many reasons why NFS is superior to sshfs, but not for casual use, where sshfs is just so much easier to use).

There are many advantages to implementing filesystems in userspace, foremost are ease of development (the kernel environment is significantly more restrictive and complex) and system robustness against buggy filesystems. Porting is also a big plus. There is a small latency incurred waiting for the kernel to schedule the filesystem and then the FUSE daemon (or vice versa), but not a significant one. A possible disadvantage is that the kernel can elect to kill a filesystem process to resolve virtual memory starvation, especially if the filesystem had recently been mounted. There are also some security concerns since the FUSE implementation involves a setuid root application for handling mounts, but some care has been taken to limit the attack vectors to within the preexisting surface area (which isn't quite as secure as you might think).

So that's pretty much all you need to know about FUSE and more...

FUSE is awesome, I just found a FUSE filesystem for the Rio Karma... if I can get that compiled for OS X, I'll be able to update my Karma from my iBook. Score!

- chrish

Yeah... you'll be much happier using a filesystem that isn't absolute crap. The entire design philosophy behind FAT32 was based on the assumption that files rarely get any bigger than when they were first created. It doesn't take a computer scientist to realize that this is a deeply flawed assumption.

NTFS, on the other hand, is a fairly well-designed filesystem with some caveats. It's a log-structured filesystem, based on the assumption that on modern machines, reads will usually be satisfied from the page cache. Therefore, they optimize for write throughput. They write sequentially, sort of like FAT32, but they keep the old versions of files (and metadata) and simply write the new version at the next sequential block address. This results in far less fragmentation than FAT32, but more than the FFS-inspired (i.e. most UNIX) filesystems. Ultimately NTFS is hampered by poor read throughput and inefficient locking semantics, and its write advantages are nullified by advances in multitasking and on-disk write buffers.

UNIX filesystems tend to be designed on the assumption that writes can occur asynchronously with respect to the caller, but reads are synchronous. Therefore, they optimize for read throughput. Files are written to disk strategically to leverage spatial locality of reference. Related files (such as those in the same directory) are written close, but not too close, together, while unrelated files are scattered widely across the disk. This results in unparalleled resistance to fragmentation and excellent read throughput, at the expense of write throughput. However, writes can be buffered in memory, leaving the actual block I/O for later. The most recent filesystems, such as Reiser4 and ZFS, use this mechanism to implement transactions, which either complete or don't happen at all.

The good news for NTFS is that not all of its shortcomings are unfortunate consequences of its on-disk format. Like I said, there are some inefficient locking semantics and possibly many other programming flaws. Who knows? It's proprietary. Whatever it is, the NTFS-3G developers have managed to provide better performance in most cases than Paragon NTFS, which is a proprietary product using Microsoft's implementation. Not bad for a filesystem that hasn't been tuned yet!

One thing I recently realized that may be worth noting is that (in the last beta at least) when deleting files through Nautilus the items are sent to .Trash-user on that partition as usual. But, they don't show up in GNOME's trash bin as they do for other filesystems. Maybe it's a GNOME thing.

I believe that's a FUSE issue rather than specifically related to the NTFS driver. I've experienced the same with encfs (which is also FUSE) partitions.

Yes, you need to install it twice

I don't think the OS has anything to do with whether symlinks work or not, it is purely the file system. NTFS does have support for them they just aren't exposed by the windows ui. How are they limited? I don't know too much about them except that they exist.

They are limited in XP and 2k so that you can't symlink a folder from a network drive, eg: \compmy folder -> C:my folder won't work.

I always though it was so people didn't use thin clients and presumably so MS gets more licenses by not allowing this, but they fixed it in Vista. At least for administrators, because users with regular privileges can't use symlinks.

brilliant - still need admin rights in vista for something that should work when logged on as a normal user. now i'm sure microsoft is still microsoft after all :-)

sad.

Limiting symlink creation to admins is only the default behavior. It can be changed via policy.

secpol.msc

Local Policies | User Rights Assignment | Create symbolic links

Yeah this is due to applications not handling symlinks in Vista correctly.

BTW is it confirmed that you can make a symlink from a network share to a local mount point in Vista? I've just read two things that contradict each other.

Edited 2007-02-22 00:05

Remote to Local links are possible, but this is also disabled by default for security reasons.

The default settings for symlink evaluation are:
Local to local symbolic links are enabled
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to Remote symbolic links are disabled.

You can enable remote to local and remote to remote link evaluation either via fsutil's symlinkevaluation context:

fsutil behavior symlinkevaluation (query | set)

or via the group policy editor:

gpedit.msc

Local Computer Policy | Computer Configuration | Administrative Templates | System | NTFS Filesystem | Selectively allow the evaluation of a symbolic link

Check this link for some documentation on symbolic links in Windows and link creation.
http://msdn2.microsoft.com/en-us/library/aa365680.aspx

Edited 2007-02-22 00:31

Does NTFS-3G need regular defragging just like the original? And does it slowly grind to a halt as the disk fills up - like the original?

For resilience, NTFS is a great FS but it is slow and high maintenance.

I think I'd stick with native Linux file systems and share with Windows using Samba.

This has to be great for disaster recovery (for disasters such as "Oh my god! I've accidentally installed Windows")

I used the ext2 drivers for Windows for a while. I also accessed that drive from OSX, obviously using OSX ext2 drivers. In the end it was too big a hassle. It was very sensitive, I had to run fsck on it all the time. I eventually reverted to fat32. It probably didn't help that I had to disable journaling (go from ext3 to ext2) to make it work on all 3 OSs.

It's funny to me how there is a Linux driver for a Windows FS that is better than any Windows driver for a Linux FS. NTFS had to be reverse engineered while ext* is open, yet no one seems to be able to (or cares to) create a stable Windows or OSX driver.

Good drivers have been around for a while, but no good *free* drivers. And there's actually is a good reason for that - vendor API lock-in.
For a very long time, the documentation and header files for the NTIFS API (the NT Installable File System layer, i.e. the file system driver API), was not freely available. You had to shell out a lot of money, IIRC on the scale of 1000 USD, to order the IFS kit from Microsoft.
Bo Branten published a freely available ntifs.h version, but its ealier incarnations caused all sorts of problems, and it's only recently (post-2004) been good enough to rely on for something as critical as a file system driver.
In short, without good documentation, without access to the source code, and being forced into shady legal areas because of the need to poke around the system internals, there's little chance someone should have written a good free driver.

Don't laugh; all you need is a FUSE port for Windows. ;-)

- chrish

The driver focus was to provide NTFS write support, I never saw any reference to encryption, it is not expected to work.

personally, I'm not interested in encrypted volumes, but I'm interested in the support of compressed volumes and dynamic volumes used in softRAID solutions.
I'll be glad about any information about these two topics (current, if exist, support and planned support). =]