Let the user choose between ntfs-3g and ntfs kernel driver

[Nicolas Nobelis]

Binary package hint: ntfs-3g

Hello !

ok, I could be wrong with this one, but I'll still try to explain :

If you install the ntfs-3g package, ntfs-3g will be used for EVERY ntfs mount. Indeed, this package install several symlinks :
/sbin/mount.ntfs -> /sbin/mount.ntfs-3g
/sbin/mount.ntfs-3g -> <elsewhere to the ntfs-3g binary>.

The issue is with the first symlink : even if the fstab contains entries with the "ntfs" fs type (NOT ntfs-3g), mount will use the mount.ntfs command, and thus the ntfs-3g driver.

So if someone want to use only the readonly ntfs kernel driver, and from to time to time, the ntfs-3g driver (e.g. for external HD), he can't : These symlinks force him to use the ntfs-3g driver for every ntfs mount !!!

As far as I'm concerned, there are two solutions :
* remove the /sbin/mount.ntfs symlink, but this goes against the policy of "ntfs-3g by default" for everyday users
* change the /sbin/mount.ntfs to be a small script so it can read an option file (e.g. /etc/default/ntfs), containing a line :
DEFAULT_NTFS_DRIVER=ntfs-3g or DEFAULT_NTFS_DRIVER=ntfs. Thus we should be able to control the default driver.

Please tell me you thoughts, or correct me :)

Regards
N.

[Szabolcs Szakacsits (szaka)]

Hi,

I'd like to ask, why do you want to use the NTFS kernel driver?

NTFS-3G can be also used read-only with the 'ro' mount option but a memory corruption can not lead to system crash or data corruption on the disk unlike in case of the NTFS kernel driver.

Fundamentally NTFS-3G is the five years old, rewritten NTFS kernel driver plus three years more work: bug fixes, new features, actively developed/maintained, etc.

Thanks, Szaka

==
NTFS-3G: http://ntfs-3g.org

[Nicolas Nobelis (nobelis)]

Thanks for you quick reply Szaka !

Maybe I'm going to give you a wrong answer, but I've always found that ntfs-3g is more cpu-consuming than the kernel driver (not considering only the write operations, I also find the directory listings sluggish). And I've always thought this difference occurs because of the kernel mode/userspace difference.

However, with the appearance of more and more fuse-based FS, I imagine it's not the case anymore ?

You implied in your message that you can have data corruption using the kernel driver. Could you please detail ? Is this the case even in 'ro' mode ?

Regards
N.

[Szabolcs Szakacsits (szaka)]

CPU usage:

- Until very recently Ubuntu indeed used an old, very CPU consuming driver.
- The NTFS-3G CPU usage is visible in the process list which is not true for kernel drivers. This makes some people think that the driver uses a lot of CPU even if sometimes it uses less than the in-kernel Linux file systems.
- Some more are listed on http://ntfs-3g.org/support.html#cpu100
- The priority of the project is reliability. When we must chose between stability/correctness or performance then we always select the first one. No exception. We improve performance only if it doesn't impact the formers in any way.
- The driver is not optimized yet. This will happen when the time comes.

Sluggish directory listing:

Well, nobody reported this yet. Probably you mean latency. NTFS-3G indeed reads all files before showing the first one. So the delay usually is longer but afterwards it must be smoother.

Kernel/user-space difference:

Yes, there are quite a lot of myths unfortunately. Some short reading:
http://lkml.org/lkml/2008/4/18/136

Data corruptions with 'ro' drivers:

All kernel drivers are in the same, unprotected address space. If one has a bug then anything can go wrong anywhere. These do happen all the time. More readings: http://pages.cs.wisc.edu/~swift/

Regards, Szaka

[Szabolcs Szakacsits (szaka)]

Sorry, this is the link I originally intended to send in my last comment: http://pages.cs.wisc.edu/~swift/projects/drivers.html

[Nicolas Nobelis (nobelis)]

Thanks you very much Szaka for these insightful remarks.

In light of these arguments, I think that use of ntfs-3g by default in ubuntu for ntfs mounts is well deserved !

Should we close this bug then ?

[John B. (jbuncher)]

I would like to suggest not closing this bug, as I recently ran in to a damaged ntfs partition that I was unable to mount using ntfs-3g, but a friend *was* able to mount using the kernel driver. At the very least, when ntfs-3g is installed it should make a mount.ntfskernel or something so that people troubleshooting have the option of using the kernel ntfs driver.

Even if the reason why my friend was able to mount the drive was not due to differences in ntfs-3g vs kernel ntfs, we should still leave the option on the table. I have nothing against ntfs-3g as the default in ubuntu, but it seems like the kernel ntfs driver should still be accessible for troubleshooting/recovery cases where ntfs-3g might not work.

Thanks for your time.

[Szabolcs Szakacsits (szaka)]

By default the kernel driver mounts read-only, NTFS-3G read-write. Mounting read-write turns on a lot of consistency checks to protect against potential data corruptions during write. But of one uses the 'ro', read-only mount option then NTFS-3G will mount the volume the same way as the kernel driver.

Yes, many people are not aware of this, or know how to use mount options. Because of this, NTFS-3G will fall back to read-only mount automatic by default in the future versions when read-write mount is unsafe.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.