A follow up question on the new NTFS driver which is inbuilt into Kernel 7.1.x or higher

This is a follow up post with an additional few queries. In an earlier post regarding using the new NTFS driver that is inbuilt into the kernel, it was suggested that the package ntfs-3g package be uninstalled, the initramfs be rebuilt so as to use the new NTFS kernel module. I have a few follow up questions on this.

I checked that the new NTFS driver, which has an alias of fs-ntfs, is available in the Linux Kernel 7.1.x and higher. Arch still does not include it inbuilt inside the kernel rather as a separate module file. The older and more prevalent NTFS3 driver, which has an alias of fs-ntfs3, is also present as a separate module file.

My first query. The new NTFS driver is present inside 7.1.x kernel but not in LTS 6.18.x kernel and possibly not in the LTS 6.12.x kernel too. Will it be made available in these LTS kernel too? Since it was available till Linux Kernel 6.19.

My second query, the performance characteristics of the new Linux NTFS kernels are significantly more enhanced compared to the NTFS-3G kernel. They are coming very close the ext4 performances. Please see the screenshot given below for more details. Source - https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56
Does it make sense to shift ? Or should we wait since the new driver is still work in progress.

Thirdly According to an earlier post by @rabcor the new driver has a rudimentary CHKDSK like tool available. There is already a tool llike fsck.fat and fsck which can check NTFS partitions. Are those tools, i.e. fsck, lacking in some manner compared to CHKDSK?

Finally when should the new NTFS driver be used? Are there some guidelines or recommendations available?

Am keen if it can fix problems with NTSF partitions like CHKDSK on Win . Fingers crossed.:face_with_raised_eyebrow:

I wouldn’t hold my breath for this.

The ntfsfix is provided by package ntfsprogs which is actually part ofntfs-3g. However it got split off to become its own package not that long ago.

ntfsfix is rather limited in the scope of issues with a NTFS filesystem that it can fix..

Refer to:

EDIT:

I found out that there is this project:

available in AUR.

This seems to provide equivalent userspace tooling for NTFS filesystem for the new module to those provided by ntfs-3g/ntfsprogs.

However, I cannot tell how comparable it is with Windows’ CHKDSK.

seems that the VM will keep its sense. :grimacing:

My external drive WAS still in NTFS format TILL TODAY. Today it had trouble to copy simple documents. So i tried to unmount it and try to switch to a different usb port. Endeavour OS said the disc was in use and i could not unmount it at all. So i forced it to unmount because it was not used, i double checked that. Tried to mount it in a different port and guess what, it would not let me mount the drive. Tried it on a different notebook, same story so i forced it to mount the drive. Copied all the files from it and going to format it to EXT4. The drive has zero errors. In the past steam had trouble with reading my internal ntfs drive where games where installed on. Because i am a 100% linux convert i already changed that drive to EXT4. The external drive was the last one i needed to format.

My external drive is now on ext4 and i am amazed by the speed. For over 5 minutes none stop at 400-450mb writing.

Not under 330mb/s

It was never that fast in Endeavour OS when it used NTFS

Have still 2 drives left with MS-System NTFS. One HHD-Partition I’ve changed to ext4 from NTFS and there I had beside that that very old hdd runs smooth a real faster device than before. Linux may read and write NTFS but its not its provience.

I did some testing on a fully updated system (7.1.3-arch1-1) to see how the three NTFS implementations are actually selected.

My findings were:

  • ntfs3 available + ntfs-3g installed → the partition is mounted with ntfs3.
  • ntfs3 blacklisted + ntfs-3g installed → it falls back to ntfs-3g (fuseblk).
  • ntfs3 blacklisted + ntfs-3g removed → it mounts with the new ntfs driver (FSTYPE=ntfs).

I verified each case with findmnt and lsmod.

So, at least on my installation, simply removing ntfs-3g is not enough to make the system use the new ntfs driver if ntfs3 is still available. In my case it continued to use ntfs3.

ntfsprogs-plus is what i was talking about, you can see from the git page’s readme that you linked to

ntfsprogs-plus try to implement checking filesystem utility which is named ntfsck. You may think ntfsck is a linux version of chkdsk of Windows. ntfsprogs-plus use a little modified ntfs-3g library for fsck. ntfs-3g have some memory bugs and restriction. ntfsprogs-plus also try to remove memory bug and restriction.

At first release, ntfsck fully check filesystem and repair it. And not yet support journal replay.

The english is pretty mangled but they tell you to think of ntfsck as a substitute for chkdsk and the promise there is that at first release ntfsck should really be a a relatively complete replacement for chkdsk.

It’s not completely new tho it’s been around for a while in various forms.

That said cactux is right, I am not holding my breath for this working as promised. But it’s probably better than what we had, since anything is better than nothing.


That performance chart in the OP is really interesting, I didn’t know ntfs3 was this close to ext4 in performance (and this much faster than ntfs-3g, holy cow i knew it was faster but not 5x faster)

But the new driver is not covered in that image, the ntfs3-paragon driver is ntfs3 not ntfsplus, ntfsplus is supposed to be even faster than ntfs3, not sure if that actually holds up or not though, would need to benchmark it.

Does it make sense to shift ? Or should we wait since the new driver is still work in progress.

I answered this in my post that you linked to.

If you don’t mind risking data loss, corruption, fragmentation and all the usual filesystem problems, also worst case accelerated drive failure rate; you can try the new driver. And I’m pretty sure if trying the new drive for a day was gonna truly mess up your partition, they wouldn’t have released it to us yet (seems made by people who know what they’re doing, it’s even written in C so it’s not one of those ridiculous and pointless rust rewrites)

As for when to feel safe to adopt it? I’d say wait a year, check what kind of problems people have been having with it over that year, then decide if it seems safe enough for you yet. If not, wait another year and repeat. Eventually this driver will be made the default in the kernel, at that point it’s also probably a safe bet to start using it. As the poster before me confirmed, it is not yet the default.

See here:

Some file systems have multiple drivers available. Udisks allows setting preferred driver order by setting a corresponding fs_drivers line.

One such example is NTFS. Udisks prefers the ntfs3 driver by default (ntfs_drivers=ntfs3,ntfs). To use the ntfs driver instead:

/etc/udisks2/mount_options.conf

[defaults]
ntfs_drivers=ntfs