Kernel NTFS driver vs NTFS-3G

Question

A more comprehensive phrased question since I lost access to the other one.

I would ask that the other one be deleted, not this one, as it should not have been migrated in the first place.

There are currently two NTFS drivers available for Linux.

The NTFS driver included in the kernel, and the userspace NTFS-3G driver that makes use of FUSE.

By all accounts, NTFS-3G works perfectly.

My question then, is if the NTFS filesystem has been successfully reverse engineered, why have the kernel NTFS team not implemented the changes in their driver? At the moment it is still marked as experimental, and there is a good chance it will destroy your data.

Note: This has absolutely nothing to do with distributions...

Solution 1

Unfortunately this is a common problem with community projects.

Once the community identifies a significant problem, projects pop up to address it. In this case, the problem is NTFS FS utilization.

Linux-NTFS (kernel FS driver), Was created first, and after a while development stalled. IMO a bad choice, it deserved priority and still does. This driver has been stable, read only, for as long as I've done Linux (over half a decade). This only addresses half of the problem, so the community looked anywhere they could.

Captive NTFS (Driver Wrapper for NTFS.SYS), was comparably easier to create. As much code already existed in other projects. The main reason the community looked on, was because NTFS.SYS is not Free Software.

NTFS-3G (Fuse), was slapped together and is fully functional. The project has the driving commercial force of Tuxera. This project addresses the original problem of utilizing NTFS from Linux. Tuxera offers a premium proprietary NTFS kernel driver, which highlights why the community needs to complete Linux-NTFS.

So with the original problem addressed, the community outcry cooled off. Which can be unfortunate, as many times the correct implementation never gets completed. When I think about it, Tuxera actually protected its proprietary kernel NTFS implementation. Creating an inferior FUSE driver, cooled the push for a solid performing GPL kernel driver.

Now just to clarify, I am a huge community project supporter/enthusiast. I just also happen to be a critic, with no kernel programming ability. FUSE has many merits, especially for specialty FS drivers. The cold hard facts still stand, Kernel FS Drivers provide much stronger performance. Writing kernel drivers takes much more time/talent, then a comparable FUSE implementation. Both of which (Time from Talented community Programmers), have always been in short supply.

I hope this explains the current situation, in regards to Linux NTFS support.

Solution 2

It's a matter of priority. Choosing to do one thing means that something else won't get done. ntfd-3g works well, so touching the kernel driver is very low priority.

Solution 3

i just asked myself this question today, actually. here's my really hazy and non-expert understanding of it.

ntfs3g isn't really a driver, it's an application. it uses FUSE (filesystem in userspace) for an interface and is cross-platform. so, while the kernel ntfs driver could possibly implement the methods used by ntfs3g (could they? i'm not sure), it'd be operating in userspace, which isn't the kernel's jurisdiction.

...that was literally just a conclusion based on one sentence i read. how does that sound to anyone who's actually educated on the subject? =)

in fact, i think i'm going to blog on this little bit. =D

Comments

[user2284570]

It did. ntfs-3g’s work is done by Tuxera. Tuxera provides paid in kernel ntfs driver only to companies.

[Jack]

Except that they are written by completely separate projects, and surely it is important for the kernel to have a driver that actually works?

[Ignacio Vazquez-Abrams]

The fact that they're separate projects is irrelevant. In fact, that makes it worse since you need to find someone that has both kernel filesystem module knowledge and NTFS knowledge in order to be able to write the kernel driver.

[Jack]

No, it isn't irrelevant. At the moment the kernel does not have NTFS write support, when it is clearly possible. Instead, a 3rd party solution is needed. Your answer is akin to saying why bother to develop Gnome, when KDE does the job just fine. It isnt quite an apt analogy, as both gnome and KDE are completely functional, but you get the point...

[Ignacio Vazquez-Abrams]

Gnome and KDE also have different purposes. What would a kernel driver do that a FUSE driver wouldn't?

[Jack]

You're missing the point. There are many advantages to having a working NTFS driver in the kernel, without having to rely on a third party userspace driver. In any case, the answer to my question is not "because ntfs-3g works very well". If you have Project X and Project Y, both of whic have the same common goal and Project Y gets their first, Projec X is not going to give up. In fact, we see the opposite of that all too often.

[Amit Naidu]

What would a kernel driver do that a FUSE driver wouldn't? : Free up the CPU for other processes on embedded systems by not pegging it at 100%. See Ubuntu, Mageia, Ubuntu, ArchLinux, openSUSE etc.

[user2284570]

@IgnacioVazquez-Abrams because being almost always single thread cpu bound, it’s writing 3 times slower compared to the native ntfs.sys on Windows?

[Allen]

This is apparently a renewed effort to get an ntfs kernel with more features than the original including write support. It is called NTFS3, see: phoronix.com/…

[J. M. Becker]

Yea, looks like Paragon has decided to upstream their NTFS kernel driver.