The open source, freely available, stable read/write NTFS driver, NTFS-3G 1.0 has just been released. The driver, released half year ago for beta testing, made progress, thanks to ten or even hundreds of thousands testers, early adopters, and developers. In consequence of the open communications and positive experiences, NTFS-3G is available for over 60 Linux distributions today, including most major ones. Moreover it was ported to new operating systems like FreeBSD, BeOS, Haiku, and Mac OS X.
Stable read / write support for NTFS is something the Linux desktop has been sorely needing for those willing to try out linux, but afraid of going all the way.
Not only that, but this is pretty easy to use for new to Linux users thanks to ntfs-config:
http://linux.softpedia.com/progScreenshots/Ntfs-config-Screenshot-2…
http://revu.tauware.de/details.py?upid=4412
This is a bigger deal than some might realize
Edit:
The upstream ntfs-config page is dead for some reason.
Edited 2007-02-21 17:22
Since it’s a fuse-driver, it will never be merged in the kernel (But maybe parts of it?).
Anyway, Fuse exists for Mac OS also (Unstable?), so us Mac-users can use this driver as well.
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
My data drive is Fat32 so Windows & Linux can read it, I am thinking about geting PC-BSD later, I hope this is on the site as a .pbi by then.
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!
S-u-u-u-h-h-h-h-w-w-w-w-e-e-e-e–t!!!
edit: Oops, mispelling, although I sure there was a lot of sweat also.
Edited 2007-02-21 18:08
I’ve been using it since the first beta came out, and the worst I experienced was some files not deleting. But it’s been a while since I’ve seen that.
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 had been using this thing for months thinking that deleting files was as instant and permanent as ‘rm’, since they didn’t show up in the bin. I was pleasantly surprised to find that I had a couple of more gigs on my windows partion than I thought after I finally got rid of these files.
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.
(Except UMS-users.)
All it needs is a Solaris port aswell (althought better would be if everything and it’s dog got ZFS support instead.)
did they sort out the problem getting it to work with 64bit operating systems?
Yes, you need to install it twice
I wonder if this is one of those areas where Microsoft will say it has IP, such as it did with FAT?
The man pages of ntfs-3g say they support symbolic links (softlinks / symlinks). I guess that creating a symlink on a ntfs partition will work in linux, but not in windows? Windows softlink support is very limited.
I’m planning to move all my data to a new harddisk, and I’m still unsure about which filesystem to use. Both windows and linux must access the data. Ext2 drivers exists for windows, but matt’s driver lacks networking support and stefan’s driver has no unicode support. Both lack softlink support. (It would be great if symlinks would show up as .LNK files in windows, but such a feature would require another layer, and probably slow down the driver.)
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”)
We got a stable release (many users are probably afraid of beta filesystems – rightfully).
It is worth mentioning that this is a fork of ntfs-progs, developed by author of 3G as well as other people. AFAIK, he started his fork after author of original became employed by Apple and project became dual-licensed. I still don’t have idea what is happening to “Apple” driver. Maybe there will be surprises in the next OSX.
At last, it comes! I’ll be able to edit my MP3 ID3 under linux. Btw, for those who still use FAT for data, EXT2 drivers do exist for Windows. Performance aren’t realy impressive, but it still a better choice than FAT, especially with disk fragmentation FAT is prone to. I’d still like to see some Reiser3 driver for Windows through
Ho and do anybody know if FUSE as been ported to REACTOS? It could be too cool to use it with NTFS partitions.
Edited 2007-02-21 20:13
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.
I’m still waiting for a port for windows, since it seems NTFS-3g can do more with NTFS than Windows :>
Don’t laugh; all you need is a FUSE port for Windows. 😉
– chrish
Has anyone tested this with a client system that uses Windows Vista Ultimate and has BitLocker running?
http://www.microsoft.com/windows/products/windowsvista/features/det…
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). =]