Arch Linux User Repository

Note: the driver was merged to the upstream kernel in 5.15. So this package is useless for Arch official kernels.
If you want bleeding edge updates, use ntfs3-dkms-git.

Readme
More info and tips
How to use DKMS modules
Paragon NTFS3 FAQ

I made some test using bonnie and pts, this driver seems to be much faster than ntfs-3g

http://moodle.math.sk/~doug/bonnie_ntfs3_paragon.html

http://moodle.math.sk/~doug/bonnie_ntfs-3g.html

(disregard the read tests, since they were done from page cache)

edit: compilebench in pts, now includes native ext4, the paragon ntfs3 driver performance is comparable

https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56

@Hanabishi, compilation is OK with all patches applied : thanks again. :-)

@Why? I had applied only the first one commented because it was the only one stamped 5.15 from which I took the sources. ;-)

I applied two patches : Makefile.patch and kernel-5.15-backport.patch

Why? I said lines 48-50. You need to apply all 3 backport patches in the strict order:

patch -p1 -N -i "${srcdir}/kernel-5.15-backport.patch"
patch -p1 -N -i "${srcdir}/kernel-5.14-backport.patch"
patch -p1 -N -i "${srcdir}/kernel-5.12-backport.patch"

Because you are targeting 5.10, it needs the whole downgrade chain.
And you don't need Makefile.patch, it's only for DKMS package.

I tried to compile Linux-LTS 5.10.83 with NTFS3 backported but I get an error.

after extracting the fs/ntfs3/ folder from the linux-5.15.6 archive, I applied two patches : Makefile.patch and kernel-5.15-backport.patch (which is in comment in the PKGBUILD file).

I then moved the patched ntfs3/ folder to the linux-5.10.83/fs/ folder and modified linux-5.10.83/fs/Makefile and linux-5.10.83/fs/Kconfig as indicated.

some questions are asked after launching makepkg :

...
NTFS Read-Write file system support (NTFS3_FS) [N/m/y/?] (NEW) y
  64 bits per NTFS clusters (NTFS3_64BIT_CLUSTER) [N/y/?] (NEW) n
  activate support of external compressions lzx/xpress (NTFS3_LZX_XPRESS) [N/y/?] (NEW) y
  NTFS POSIX Access Control Lists (NTFS3_FS_POSIX_ACL) [N/y/?] (NEW) n

then the compilation started but stopped on the backport :

...
  CC      fs/ntfs3/attrib.o
  CC      fs/ntfs3/attrlist.o
  CC      fs/ntfs3/bitfunc.o
  CC      fs/ntfs3/bitmap.o
  CC      fs/ntfs3/dir.o
  CC      fs/ntfs3/fsntfs.o
fs/ntfs3/fsntfs.c: In function 'ntfs_bio_fill_1':
fs/ntfs3/fsntfs.c:1602:38: error: 'BIO_MAX_VECS' undeclared (first use in this function); did you mean 'BIO_MAX_PAGES'?
 1602 |                 new = ntfs_alloc_bio(BIO_MAX_VECS);
      |                                      ^~~~~~~~~~~~
      |                                      BIO_MAX_PAGES
fs/ntfs3/fsntfs.c:1602:38: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:280: fs/ntfs3/fsntfs.o] Error 1
make[1]: *** [scripts/Makefile.build:497: fs/ntfs3] Error 2
make: *** [Makefile:1822: fs] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

@Hanabishi, thanks a lot ! :-)

@lacsaP, the package already contains backport patches.

If you don't want to use DKMS and want to include it in the custom kernel build, well:
1) Extract fs/ntfs3 source from 5.15.
2) Apply the backport patches to it. (See lines 48-50 in the PKGBUILD as example.)
3) Put the sources into your kernel tree. Don't forget to include it in fs/Makefile and fs/Kconfig (again, see how it's done in 5.15).
4) Build the kernel.

@Hanabishi, could you give (me) explanations on how to backport NTFS3 on Linux-LTS (with, if possible, the non use of DKMS) ? may be in PKGBUILD file... regards, lacsaP

Well, 5.15 update is rolled out. Mainline users can uninstall the package now. But I will continue to update it to provide a backport for LTS users.
For those who wants the bleeding edge updates, even on 5.15+ (for testing or whatever reason), there is git package version.

@theriddick, I still think there are some issues with your system, not the driver.
Anyway, all the kernel discussion made through mailing lists. Here is ntfs3 archive: https://lore.kernel.org/ntfs3/, you can respond there or email directly to ntfs3@lists.linux.dev.

Getting some MAJOR integrity issues with this driver and my NTFS SSD's and NVMe drives. Is there a place I can bug report? I'm needing to freq jump into windows10 to fix my drives.. something is very wrong!

Btw 5.15 kernel was released recently. So soon all mainline kernel users will not need this package anymore

You bet I'm frequently checking the repos to see 5.15 land on Arch. I am assuming/hoping that the vanilla arch config will have this and ksmbd enabled.

@Hanabishi yeah I dunno; but I ran 'lsmod | grep ntfs3' to see if it was loaded and it wasn't. But I seem to have figured it out in the end anyway.

@theriddick, this is strange, by default fs drivers does not require to be loaded manually. Driver loads on mount automatically, you don't need to include it on boot or run modprobe. You sure have some exotic system/kernel configuration.

@Hanabishi I fixed the issue and explained how and why it wasn't working. Just ignore me.

ntfs3 module was just not auto loading, it installed fine, but wasn't added into module load on boot.

@theriddick, maybe provide some details. I doubt that someone has oracle abilities here.

Btw 5.15 kernel was released recently. So soon all mainline kernel users will not need this package anymore.

Module installs but does not load! Just requires me to add the module ntfs3 to load on boot manually by editing mkinitcpio.conf I think.

@karu1, 189 MiB.

Also for now the package forced to download an archive with the whole kernel tree. Sorry, not found a better solution for now. If you know how to improve the packaging process, please share.

what is the download size

@DDoSolitary, yeah, good point.

Please bump epoch in PKGBUILD when switching versioning scheme

New pull request was merged into the kernel upstream. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86a44e9067c95083d5dbf5a140e3f4560e5af1ca
Seems like old versioning model has gone for sure. So the package also changed versioning accordingly.
New version contains some breaking changes in mount options list, check out new readme.

Also for now the package forced to download an archive with the whole kernel tree. Sorry, not found a better solution for now. If you know how to improve the packaging process, please share.

2021-10-5 When the kernel is upgraded to 5.14.9-2-ARCH, it is working normally.

2021-9-30 It should be a system problem, I can only wait for the system to update later.

There was a problem with the upgrade, and even if reuse the pull source build, still reported an error.

DKMS make.log for ntfs3-27.0.0 for kernel 5.14.8-1-ARCH (aarch64)
2021年 09月 29日 星期三 00:17:35 CST
make -C /lib/modules/5.14.8-1-ARCH/build M=/var/lib/dkms/ntfs3/27.0.0/build modules
make[1]: 进入目录“/usr/lib/modules/5.14.8-1-ARCH/build”
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/attrib.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/attrlist.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/bitfunc.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/bitmap.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/dir.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/fsntfs.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/frecord.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/file.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/fslog.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/inode.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/index.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/lznt.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/namei.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/record.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/run.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/super.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/upcase.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/xattr.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/lib/decompress_common.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/lib/lzx_decompress.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/lib/xpress_decompress.o
  LD [M]  /var/lib/dkms/ntfs3/27.0.0/build/ntfs3.o
  MODPOST /var/lib/dkms/ntfs3/27.0.0/build/Module.symvers
ERROR: modpost: "set_bh_page" [/var/lib/dkms/ntfs3/27.0.0/build/ntfs3.ko] undefined!ERROR: modpost: "vm_zone_stat" [/var/lib/dkms/ntfs3/27.0.0/build/ntfs3.ko] undefined!
ERROR: modpost: "balance_dirty_pages_ratelimited" [/var/lib/dkms/ntfs3/27.0.0/build/ntfs3.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:150：/var/lib/dkms/ntfs3/27.0.0/build/Module.symvers] 错误 1
make[2]: *** 正在删除文件“/var/lib/dkms/ntfs3/27.0.0/build/Module.symvers”
make[1]: *** [Makefile:1773：modules] 错  2
make[1]: 离开目录“/usr/lib/modules/5.14.8-1-ARCH/build”
make: *** [Makefile:42：all] 错误 2

@Hanabishi my bad, I was actually still on the previous pkgrel, thanks for maintaing this.

@BachoSeven, can't reproduce. Ensure you are using the latest package version.

Failed building against linux-zen version 5.14.2.zen1-2:

DKMS make.log for ntfs3-27.0.0 for kernel 5.14.2-zen1-2-zen (x86_64)
ven 10 set 2021, 21:33:52, CEST
make -C /lib/modules/5.14.2-zen1-2-zen/build M=/var/lib/dkms/ntfs3/27.0.0/build modules
make[1]: Entering directory '/usr/lib/modules/5.14.2-zen1-2-zen/build'
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/attrib.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/attrlist.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/bitfunc.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/bitmap.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/dir.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/fsntfs.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/frecord.o
  CC [M]  /var/lib/dkms/ntfs3/27.0.0/build/file.o
/var/lib/dkms/ntfs3/27.0.0/build/file.c:1230:27: error: initialization of ‘struct posix_acl * (*)(struct inode *, int)’ from incompatible pointer type ‘struct posix_acl * (*)(struct inode *, int,  bool)’ {aka ‘struct posix_acl * (*)(struct inode *, int,  _Bool)’} [-Werror=incompatible-pointer-types]
 1230 |         .get_acl        = ntfs_get_acl,
      |                           ^~~~~~~~~~~~
/var/lib/dkms/ntfs3/27.0.0/build/file.c:1230:27: note: (near initialization for ‘ntfs_file_inode_operations.get_acl’)
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:271: /var/lib/dkms/ntfs3/27.0.0/build/file.o] Error 1
make[1]: *** [Makefile:1848: /var/lib/dkms/ntfs3/27.0.0/build] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.14.2-zen1-2-zen/build'
make: *** [Makefile:42: all] Error 2

Anyway, I see the problem. Latest changes were actually for 5.15. Fixed, made a disctinct patch from it.

@Ranguvar, the main patch in prepare() applies regardless of kernel version. Maybe you mean backport patches applied in dkms.conf? You can't build the package itself or dkms build fails?

Fails to build against 5.14.1.

Some of the patches in prepare() seem to fail.

27.0.0-2 still works well.

@Hanabishi Nice,now can be used normally.

@hianghokung, fixed.

I have the following error report and it is not working properly now. Ask for help.

:: 正在运行事务后钩子函数... (1/2) Arming ConditionNeedsUpdate... (2/2) Install DKMS modules ==> dkms install --no-depmod -m ntfs3 -v 27.0.0 -k 5.10.60-1-ARCH Error! Application of patch kernel-5.12-backport.patch failed. Check /var/lib/dkms/ntfs3/27.0.0/build/ for more information. ==> Warning, `dkms install --no-depmod -m ntfs3 -v 27.0.0 -k 5.10.60-1-ARCH' returned 6 ==> depmod 5.10.60-1-ARCH

NTFS3 was merged into the kernel tree.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7464060f7ab9a2424428008f0ee9f1e267e410f

@Hanabishi There is new xanmod out so I'll just build that. It has this driver from 3 days ago which should be new enough.

@theriddick, idk for sure, but I suppose the patch is not compatible with it.

@Hanabishi No not yet, I'm using the one in Xanmod. If I install the git DKMS will that overwrite the xanmod version?

@theriddick, did you tried the latest version from git? v27 has confirmed corruption bugs. In the git version there are lot of fixes.

I've had a few issues now with ntfs3 driver where my drives integrity would go down or something and files would go missing. I'd boot into Win10 and run a scan disk and repair the drive, and low and behold, those missing and bad files return... This is like the 3rd time its happened, its almost asif this drive is not writing data correctly to the drive.

No windows10 hibernation is set btw. So windows is not to blame for this issue (not to mention I never boot into windows lately)

@esistgut, they are still not published the utils, I guess.
By now checking NTFS in Linux is not recommended at all. ntfs-3g tools also not working well https://wiki.archlinux.org/title/NTFS-3G#Damaged_NTFS_filesystems

p.s. You can mount 'dirty' partitions via force flag. If you are sure there is no real errors and fs is just not closed gracefully. But still better use Windows chkdsk just for sure.

After an hard reboot my system did not boot because my partition got the dirty flag and couldn't be mounted. I had to reboot on Windows to check and unflag it. The Paragon FAQs have references to Linux tools (chkNTFS and mkNTFS). Do you know how to get them?

There is now upstream git repo exist. But no new defined version released yet.
I've created ntfs3-dkms-git package https://aur.archlinux.org/packages/ntfs3-dkms-git/

@Hanabishi, perhaps, I dunno. It did use to work but I had some issue recently and had to disable ntfs3 included in xanmod, and thought I'd try this dkms one.

Guess I'll just wait until 5.15+

@theriddick, well, maybe this is the cause. The package is only tested for Arch with officially supported kernels.

@Hanabishi, I had been just trying to mount with gnome-disk-utility, but I'm using xanmod 5.13-8 kernel atm. Xanmod may have ntfs3 already but it failed on me for unknown reasons so I installed this one.

dkms status says their installed. lsmod shows ntfs3 in the list...

Example of it done in tty: sudo mount -t ntfs3 /dev/sdb2 /mnt/StorageSSD/

mount: /mnt/StorageSSD: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error.

@theriddick, can you provide more details? Which kernel version, dkms module installation output. Which exact command are you using and it's output.

Tried to get this working but whenever I attempt mount it spits this. wrong fs type, bad option, bad superblock on xxx, missing codepage or helper program, or other error udisks-error-quark, 0

I've tried with no mount flags also and same issue.

@loathingkernel, no real point. Will remove it next time.

What is the point of this package conflicting with itself?

Thank you.

@post-factum, yeah, done.

Mind adding provides=(NTFS3-MODULE)?

@Hanabishi, Thank you very much.

Well, regardless, here is an update. Now the package has 2 backport patches.
Because <5.12 users will still need both patches in the future.

Seems like the only change in v27 is for 5.14 kernel version. Backporting is literally equal to reverting back to v26 state.
So the package update to v27 is not possible until Arch mainstream kernel will be updated to 5.14.

@yanpas, well, the best way I think is to reply to the ntfs3 message at lkml https://lore.kernel.org/lkml/20210402155347.64594-1-almaz.alexandrovich@paragon-software.com/#R

@Hanabishi It's new Western Digital USB hard drive that I've bought today to do backups. CrystalDiskInfo and Windows shows it's 100% healthy. ntfs-3g works as a charm. I was copying about 160GB of various photos and videos, there are a lot of Cyrillic paths BTW.

Do you know how to send my feedback to Paragon?

@yanpas, looks like the disk failure. Are you sure it's ok? You tested it with ntfs-3g and in Windows?

Don't recommend using with rsync and writing, tons of errors in dmesg:

[ 5529.507567] INFO: task kworker/0:1:18 blocked for more than 1105 seconds.
[ 5529.507580]       Tainted: P           OE     5.13.4-arch1-1 #1
[ 5529.507584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5529.507586] task:kworker/0:1     state:D stack:    0 pid:   18 ppid:     2 flags:0x00004000
[ 5529.507598] Workqueue: usb_hub_wq hub_event
[ 5529.507612] Call Trace:
[ 5529.507615]  ? out_of_line_wait_on_bit_lock+0xb0/0xb0
[ 5529.507631]  __schedule+0x310/0x930
[ 5529.507641]  ? out_of_line_wait_on_bit_lock+0xb0/0xb0
[ 5529.507648]  schedule+0x5b/0xc0
[ 5529.507654]  bit_wait+0xd/0x60
[ 5529.507661]  __wait_on_bit+0x2a/0x90
[ 5529.507669]  __inode_wait_for_writeback+0xb0/0xe0
[ 5529.507680]  ? var_wake_function+0x20/0x20
[ 5529.507689]  writeback_single_inode+0x64/0x140
[ 5529.507699]  sync_inode_metadata+0x3d/0x60
[ 5529.507712]  ntfs_set_state+0x126/0x1a0 [ntfs3]
[ 5529.507738]  ni_write_inode+0x244/0xef0 [ntfs3]
[ 5529.507764]  ? pagevec_lookup_range_tag+0x24/0x30
[ 5529.507772]  ? __filemap_fdatawait_range+0x6f/0xf0
[ 5529.507785]  __writeback_single_inode+0x260/0x310
[ 5529.507795]  writeback_single_inode+0xa7/0x140
[ 5529.507803]  sync_inode_metadata+0x3d/0x60
[ 5529.507814]  ntfs_set_state+0x126/0x1a0 [ntfs3]
[ 5529.507834]  ntfs_sync_fs+0xf9/0x100 [ntfs3]
[ 5529.507857]  sync_filesystem+0x40/0x90
[ 5529.507868]  fsync_bdev+0x21/0x60
[ 5529.507874]  delete_partition+0x13/0x80
[ 5529.507882]  blk_drop_partitions+0x5b/0xa0
[ 5529.507889]  del_gendisk+0xa5/0x220
[ 5529.507895]  sd_remove+0x3d/0x80
[ 5529.507907]  __device_release_driver+0x17a/0x230
[ 5529.507918]  device_release_driver+0x24/0x30
[ 5529.507927]  bus_remove_device+0xdb/0x140
[ 5529.507937]  device_del+0x18b/0x400
[ 5529.507943]  ? ata_tlink_match+0x30/0x30
[ 5529.507949]  ? attribute_container_device_trigger+0xc5/0x100
[ 5529.507959]  __scsi_remove_device+0x118/0x150
[ 5529.507967]  scsi_forget_host+0x54/0x60
[ 5529.507978]  scsi_remove_host+0x72/0x110
[ 5529.507988]  usb_stor_disconnect+0x46/0xb0 [usb_storage]
[ 5529.508003]  usb_unbind_interface+0x8a/0x270
[ 5529.508010]  ? kernfs_find_ns+0x35/0xd0
[ 5529.508017]  __device_release_driver+0x17a/0x230
[ 5529.508027]  device_release_driver+0x24/0x30
[ 5529.508036]  bus_remove_device+0xdb/0x140
[ 5529.508044]  device_del+0x18b/0x400
[ 5529.508050]  ? kobject_put+0x98/0x1d0
[ 5529.508062]  usb_disable_device+0xc6/0x1f0
[ 5529.508073]  usb_disconnect.cold+0x7e/0x250
[ 5529.508085]  hub_event+0xc7b/0x17f0
[ 5529.508099]  process_one_work+0x1e3/0x3b0
[ 5529.508109]  worker_thread+0x50/0x3b0
[ 5529.508115]  ? process_one_work+0x3b0/0x3b0
[ 5529.508122]  kthread+0x133/0x160
[ 5529.508127]  ? set_kthread_struct+0x40/0x40
[ 5529.508133]  ret_from_fork+0x22/0x30

[ 8440.627659] blk_update_request: I/O error, dev sdd, sector 256017240 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.627667] ntfs3: 165 callbacks suppressed
[ 8440.627667] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8440.627673] blk_update_request: I/O error, dev sdd, sector 256017240 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.627676] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8440.778355] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.778384] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8440.778412] blk_update_request: I/O error, dev sdd, sector 6353096 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.778428] ntfs3: sdd1: failed to read volume at offset 0xc1d19000
[ 8440.778441] blk_update_request: I/O error, dev sdd, sector 6353096 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.778452] ntfs3: sdd1: failed to read volume at offset 0xc1d19000
[ 8440.778459] ntfs3: sdd1: ntfs_evict_inode r=0 failed, -22.
[ 8440.778489] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.778500] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8440.789598] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.789606] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8440.789628] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.789631] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8440.789642] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8440.789644] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8440.792779] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8459.095591] print_req_error: 84 callbacks suppressed
[ 8459.095593] blk_update_request: I/O error, dev sdd, sector 256017240 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8459.095599] ntfs3: 85 callbacks suppressed
[ 8459.095600] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8459.095606] blk_update_request: I/O error, dev sdd, sector 256017240 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8459.095609] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8471.614409] blk_update_request: I/O error, dev sdd, sector 2400 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0
[ 8471.614426] Buffer I/O error on dev sdd1, logical block 44, lost async page write
[ 8471.614459] blk_update_request: I/O error, dev sdd, sector 6293576 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0
[ 8471.614467] Buffer I/O error on dev sdd1, logical block 786441, lost async page write
[ 8471.614501] blk_update_request: I/O error, dev sdd, sector 6353104 op 0x1:(WRITE) flags 0x100000 phys_seg 6 prio class 0
[ 8471.614507] Buffer I/O error on dev sdd1, logical block 793882, lost async page write
[ 8471.614512] Buffer I/O error on dev sdd1, logical block 793883, lost async page write
[ 8471.614516] Buffer I/O error on dev sdd1, logical block 793884, lost async page write
[ 8471.614520] Buffer I/O error on dev sdd1, logical block 793885, lost async page write
[ 8471.614524] Buffer I/O error on dev sdd1, logical block 793886, lost async page write
[ 8471.614528] Buffer I/O error on dev sdd1, logical block 793887, lost async page write
[ 8471.614544] blk_update_request: I/O error, dev sdd, sector 6353176 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0
[ 8471.614549] Buffer I/O error on dev sdd1, logical block 793891, lost async page write
[ 8527.251772] blk_update_request: I/O error, dev sdd, sector 256017240 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.251782] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8527.251790] blk_update_request: I/O error, dev sdd, sector 256017240 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.251794] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8527.403651] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.403681] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8527.403710] blk_update_request: I/O error, dev sdd, sector 6353176 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.403726] ntfs3: sdd1: failed to read volume at offset 0xc1d23000
[ 8527.403740] blk_update_request: I/O error, dev sdd, sector 6353176 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.403751] ntfs3: sdd1: failed to read volume at offset 0xc1d23000
[ 8527.403758] ntfs3: sdd1: ntfs_evict_inode r=0 failed, -22.
[ 8527.403780] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.403790] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8527.413483] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.413490] ntfs3: sdd1: failed to read volume at offset 0xbffff000
[ 8527.413497] blk_update_request: I/O error, dev sdd, sector 6353176 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.413500] ntfs3: sdd1: failed to read volume at offset 0xc1d23000
[ 8527.413503] blk_update_request: I/O error, dev sdd, sector 6353176 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8527.413505] ntfs3: sdd1: failed to read volume at offset 0xc1d23000
[ 8527.413512] blk_update_request: I/O error, dev sdd, sector 6293496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8534.121680] print_req_error: 63 callbacks suppressed
[ 8534.121682] blk_update_request: I/O error, dev sdd, sector 6293576 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0
[ 8534.121685] Buffer I/O error on dev sdd1, logical block 786441, lost async page write
[ 8534.121695] blk_update_request: I/O error, dev sdd, sector 6353104 op 0x1:(WRITE) flags 0x100000 phys_seg 2 prio class 0
[ 8534.121697] Buffer I/O error on dev sdd1, logical block 793882, lost async page write
[ 8534.121698] Buffer I/O error on dev sdd1, logical block 793883, lost async page write
[ 8534.121702] blk_update_request: I/O error, dev sdd, sector 6353128 op 0x1:(WRITE) flags 0x100000 phys_seg 2 prio class 0
[ 8534.121704] Buffer I/O error on dev sdd1, logical block 793885, lost async page write
[ 8534.121705] Buffer I/O error on dev sdd1, logical block 793886, lost async page write
[ 8534.121708] blk_update_request: I/O error, dev sdd, sector 6353184 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0
[ 8534.121709] Buffer I/O error on dev sdd1, logical block 793892, lost async page write
[ 8534.121715] blk_update_request: I/O error, dev sdd, sector 6353216 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0
[ 8534.121716] Buffer I/O error on dev sdd1, logical block 793896, lost async page write
[ 8547.435352] blk_update_request: I/O error, dev sdd, sector 7342592 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 8547.435367] blk_update_request: I/O error, dev sdd, sector 7342592 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8547.913816] blk_update_request: I/O error, dev sdd, sector 29120088 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 8547.913827] blk_update_request: I/O error, dev sdd, sector 29120088 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8547.942442] blk_update_request: I/O error, dev sdd, sector 29131080 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
[ 8547.942453] blk_update_request: I/O error, dev sdd, sector 29131080 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8547.971605] blk_update_request: I/O error, dev sdd, sector 29150832 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
[ 8547.971622] blk_update_request: I/O error, dev sdd, sector 29150832 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8548.000941] blk_update_request: I/O error, dev sdd, sector 29160776 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
[ 8548.000952] blk_update_request: I/O error, dev sdd, sector 29160776 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8549.202253] ntfs3: 66 callbacks suppressed
[ 8549.202257] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000
[ 8549.202275] ntfs3: sdd1: failed to read volume at offset 0x1e84f6b000

@yanpas, maybe just the mount time is long for some reason. Try to disable automount on boot (noauto) and measure the mount time when you manually mounting it.

@Hanabishi 5.13.4. Actually I faced this every kernel release for the last several months. While booting I see two lines in console (systemd version and some other line) and hdd led constantly flickering.

@yanpas, which kernel are you using?

Slow boot

I use this driver in fstab:

    /dev/disk/by-uuid/XXXXXXXXXXX /home/me/.D/ ntfs3 rw,users,uid=me,gid=me,dmask=027,fmask=137,nofail 0 0

For some reason the system has started booting much slower (fsck is disabled according to fstab). Does anyone know the reason? dmesg log:

[    3.526953] usbcore: registered new interface driver usbhid
[    3.526954] usbhid: USB HID core driver
[    3.550022] ntfs3: module verification failed: signature and/or required key missing - tainting kernel
[    3.607304] mousedev: PS/2 mouse device common for all mice
[    3.609199] ntfs3: Index binary search
[    3.609200] ntfs3: Hot fix free clusters
[    3.609200] ntfs3: Max link count 1024
[    3.609201] ntfs3: Enabled Linux POSIX ACLs support
[    3.609201] ntfs3: Activated 32 bits per cluster
[    3.609202] ntfs3: Read-only lzx/xpress compression included
[    3.856553] nvidia: module license 'NVIDIA' taints kernel.

Note: the driver was merged to the upstream kernel in 5.15. So this package is useless for Arch official kernels.
If you want bleeding edge updates, use ntfs3-dkms-git.

Readme
More info and tips
How to use DKMS modules
Paragon NTFS3 FAQ

@Hanabishi Thanks.

@lignix, the answer is directly in your logs: Missing kernel headers. You should install the kernel headers (e.g. linux-headers package).
Read how to use DKMS modules: https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support

Hi my kernel version 5.12.10-arch1-1

compilation gives error:

==> fakeroot ortamından çıkılıyor.
==> ntfs3-dkms 26.0.0-4 (Pzt 28 Haz 2021 15:22:24) paketinin derlenmesi tamamlandı
==> Temizleniyor...
paketler yükleniyor...
paket bağımlılıkları çözümleniyor...
varsa paketler arası çakışmalara bakılıyor...

Paketler (1) ntfs3-dkms-26.0.0-4

Toplam Kurulum Boyutu:  0,70 MiB

:: Kuruluma onay veriyor musunuz? [E/h] 
(1/1) anahtarlıktaki anahtarlar kontrol ediliyor                                                           [###############################################################] 100%
(1/1) paket bütünlüğü kontrol ediliyor                                                                     [###############################################################] 100%
(1/1) paket dosyaları yükleniyor                                                                           [###############################################################] 100%
(1/1) dosya çakışmaları kontrol ediliyor                                                                   [###############################################################] 100%
(1/1) disk alanı kontrol ediliyor                                                                          [###############################################################] 100%
:: Paket değişiklikleri işleniyor...
(1/1) yükleniyor ntfs3-dkms                                                                                [###############################################################] 100%
:: Bağlantılı işlemler listesi çalışıyor...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Install DKMS modules
==> Unable to install module ntfs3/26.0.0 for kernel *: Missing kernel headers.

what is the problem?

@Hanabishi I should've mentioned that I have symlinked compatdata out of the NTFS partition (I don't think compatdata was causing issues in itself). It seems to happen when Steam updates games (I get the impression Steam hits the FS pretty hard).

It can read files with NTFS compression (even new methods from Win10). But what about write - can't say how to do that in linux. There is sparse mount flag, but I don't know how it works.
Btw du util only shows an actual file size without compression. And there is no such util for NTFS like compsize for BTRFS.

Ntfs3 doesn't support sparse files?

$ truncate -s 512M file.img

NTFS3:

$ du -h file.img

512M file.img

EXT4:

$ du -h file.img

0 file.img

Doh, neglected to clean my cache directory... building fine now, thanks!

@jason.houston try cleaning the aur clone directory. For example with paru you would do it like so paru -Sc

@jason.houston, yes. Tried it right now: all checks passed.

I'm still getting the validity check error when trying to update, did the package get updated?

Yeah, seems like something changed in lkml.
Updated the package.

sha512sums for v26.*.patch seems wrong.

@ricky26, which kind of corruption?
Wine/Proton creates files with incorrect names (like c:). So if you have issues in Windows after that, this is kinda expected result.
Btw ntfs-3g by default doesn't allow such names and Wine/Proton doesn't work with it at all. So NTFS is not the best choice for this.
As a workaround you can e.g. link Steam's compatdata directory to other filesystem.

I've experienced directory corruption with v26, I think it was introduced in one of the revisions. Seems pretty easy to reproduce by installing some large Steam games on my HDD (Proton is a good test case to exercise it with too).

I have never encountered filesystem corruption/failure using ntfs3 driver.

@alireza6677, you should read warnings. Early development unstable things really may be unstable you know.
Also if you care about your hard drives, the power outage is the way worse than any driver failure, because it can damage em physically.

This driver damaged two of my NTFS partitions after a power outage. Even windows' chkdsk couldn't fix them. Thankfully I didn't have anything too important on them.

Please don't use this crap if you care about your hard drives.

Well, I've improved the package, the legacy patch applies at DKMS build stage. So now you should be able to pre-build it anywhere and also update through 5.12 boundary (e.g. 5.11 -> 5.12) on the fly without problems.

@Saancreed, maybe, if I will figure out how to do it properly.
But yeah, seems like this thing causes some problems. Now I'm starting to think that the maintaining of the backport wasn't the great idea.

Hey there!

I've taken a look at PKGBUILD, and I've noticed that in prepare function you check for the version of the kernel currently running on the build machine. This introduces a hidden dependency on build environment, has a chance of outright not working if the machine on which the package is installed is running a different kernel version and DKMS will most likely fail to build the module if the machine has both LTS and mainline kernel (which defeats the point of using DKMS). Could you please move the check to when the module is actually compiled for given kernel version? Y'know, using the usual #if LINUX_VERSION_CODE < KERNEL_VERSION(x, y, z) like Nvidia and other out of tree kernel modules usually do.

My own package achieves it like this:

    patch -Np3 -DNTFS3_NO_USERNS -i "${srcdir}/v${pkgver}-no-userns.patch"
    sed -i '8s:^:#include <linux/version.h>\n\n#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 12, 0)\n#define NTFS3_NO_USERNS\n#endif\n\n:' ./ntfs_fs.h

One can monitor the udisks2 path regarding ntfs3 in this GitHub issue.

Basically, they're rightfully waiting to see what the final name of the merged driver will be. It is my hope that it will replace the old ntfs driver soon.

Recomended trick seems not to work for me (Manjaro, after reboot and udevadm control --reload-rules). /etc/udev/rules.d/99-ntfs.rules SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"

Veracrypt mount shows error (password for encryption is right), mount /dev/mapper/veracrypt1 /mnt/veracrypt1 mount: /mnt/veracrypt1: unknown filesystem type 'ntfs'

Yeah actually your version is better, it'll break when 6+ comes around as you say, but surely ntfs3 will be merged sooner that that (I hope, haha) and in that case you can just depend linux < (version where merge happened) or something

@jpegxguy, I don't think so. Because e.g. "4.20" will not pass the test.
My code also can be problematic tho, when 6+ will come out. But until then I think I will come up with a better idea for checking.

Good idea!

Maybe in line 52 you want [ $kmaj -le 5 ] && [ $kmin -lt 12 ] ?

I've decided to make the package universal. Just to keep support for old/lts kernel version users.
It is now automatically detects kernel version and decides to apply the compatibility patch or not.

Ah, so kernel_version_fix.patch was added because ntfs3 was normally based on 5.12 in the mailing list? Thanks for the quick answer

@jpegxguy, because it contains a patch for 5.11 or lower. Just wait when main linux package from core repo will be updated to 5.12, then I will update this package too.
Or if you want it right now, just remove

patch -p3 -N -i "$srcdir/kernel_version_fix.patch"

line form the PKGBUILD.

5.12 build error (I'm using linux-ck but I don't it's related):

DKMS make.log for ntfs3-26.0.0 for kernel 5.12.0-1-ck-zen (x86_64)
Τετ 28 Απρ 2021 04:22:09 μμ EEST
make -C /lib/modules/5.12.0-1-ck-zen/build M=/var/lib/dkms/ntfs3/26.0.0/build modules
make[1]: Entering directory '/usr/lib/modules/5.12.0-1-ck-zen/build'
  CC [M]  /var/lib/dkms/ntfs3/26.0.0/build/attrib.o
  CC [M]  /var/lib/dkms/ntfs3/26.0.0/build/attrlist.o
  CC [M]  /var/lib/dkms/ntfs3/26.0.0/build/bitfunc.o
  CC [M]  /var/lib/dkms/ntfs3/26.0.0/build/bitmap.o
  CC [M]  /var/lib/dkms/ntfs3/26.0.0/build/dir.o
  CC [M]  /var/lib/dkms/ntfs3/26.0.0/build/fsntfs.o
/var/lib/dkms/ntfs3/26.0.0/build/fsntfs.c: In function ‘ntfs_bio_fill_1’:
/var/lib/dkms/ntfs3/26.0.0/build/fsntfs.c:1623:24: σφάλμα: ‘BIO_MAX_PAGES’ undeclared (first use in this function); did you mean ‘BIO_MAX_VECS’?
 1623 |   new = ntfs_alloc_bio(BIO_MAX_PAGES);
      |                        ^~~~~~~~~~~~~
      |                        BIO_MAX_VECS
/var/lib/dkms/ntfs3/26.0.0/build/fsntfs.c:1623:24: σημείωση: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:271: /var/lib/dkms/ntfs3/26.0.0/build/fsntfs.o] Error 1
make[1]: *** [Makefile:1855: /var/lib/dkms/ntfs3/26.0.0/build] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.12.0-1-ck-zen/build'
make: *** [Makefile:40: all] Error 2

@Hanabishi Yea, I didn't notice.

@eNV25, sadly no. The patchwork is broken. Look closely, you will see that the message #4 was just lost there.
https://i.ibb.co/QDMGTpF/image.png

Incremental diff between v24 and v25: https://gitlab.com/post-factum/pf-kernel/-/commit/53c3b8a7ea40260500d85e6e9816513e0d4a70ca

Let me know if I missed something. This is compile-tested only ATM.

@babam, our problem is fixed in v22, congrats!
@post-factum, I've made a new patch by my own taking yours as example, thanks again.

Here is a file access problem on my system https://tinyimg.io/i/UdLDQkQ.png

@ignapk, not a bug. NTFS itself supports any characters, such illegal characters is just Windows restriction. Also ntfs supports case-sensitive names (and Windows 10 supports it too since WSL was introduced).
Yes, for NTFS-3G there is optional flag windows_names. You can send a such feature request to the driver devs if you want.

I think I found another bug/missing functionality: there are no checks for illegal characters in filenames, like in ntfs-3g, for example one can create files with names containing characters like " * / : < > ? \ | Can anybody else reproduce, and should I report it in the mailing list thread?

Edit: seems like what I'm looking for is equivalent of ntfs-3g "windows_names" mount option.

I've send an email with both of you in Cc, you may reply to it with detailed description of your issues, and maybe devs will reply to you.

@post-factum, thanks. Updated the package.

P.S. Access problem still not fixed. I don't know how to report it properly.

The previous fix is applicable with one minor change. I've adjusted it here:

https://gitlab.com/post-factum/pf-kernel/-/commit/e487427ef07c735fdc711a56d1ceac6629c34dcf.patch

Make sure to grab it and save somewhere because I may rewrite this branch before v5.11 is released.

@babam, sadly no.

@Hanabishi, Is the v20_fix.patch not applicable to v21?

@post-factum, we need a compatibility patch again for v21 :)

@babam, thanks for your investigation. Also have done the tests and yes, the problem is present in v18 and above.

@Hanabishi,

I have done the tests, v20, v19 and v18 have this problem, while v17 is without problem.

find /path/to/mountpoint -type d -exec ls -Al {} + 1>/dev/null

@babam, yes. And still can't figure out what exactly causes the issue. Very strange behavior: https://i.ibb.co/sv4z7Nx/image.png

The hidden attribute issue seems to be fixed according to v20 changelog + my tests.

@Hanabishi,

Does the problem of unable to access some files still occur on v20?

Problem like that didn't happen to me, v19 worked fine except for the Hidden+System attribute issue.

@post-factum, already received your message, thanks. Yes, this compatibility patch works.
I will apply it to the package for now. Until 5.12 be released on Arch.

Feel free to use this patch against v20 to make it buildable again on v5.10/v5.11: http://ix.io/2Oxa

v20 is based against linux-next, which has introduced idmappings, hence it is not compatible with present kernel releases.

@resadent, share your PKGBUILD then.

Dunno whats going on, but I tried to update to v20 myself and got it working no problem :/.

Yeah, also confirmed by kernel test robot https://lore.kernel.org/lkml/202102060418.tr1NQ8uo-lkp@intel.com/ So v20 is broken for now.

@babam, reported details here: https://lore.kernel.org/lkml/CAOehnrO-qjA4-YbqjyQCc27SyE_T2_bPRfWNg=jb8_tTetRUkw@mail.gmail.com/

@Hanabishi

What is the problem?

Update to v20 is likely screwed because it's even can't compile due to some errors in the source. LMAO.

Faced some issues. A strange problem with inability to access or delete some files, when even basic ls command fails https://i.ibb.co/41bBHZS/image.png
And behavior is very random: some times volume remounting helps, some times not. The good thing is seems like FS itself is not damaged. Accessing via ntfs-3g or Windows shows that are all the files is fine.
Can't say is that v19 issue or latest kernel updates side effect. Does anyone has the same issues?
But in any case, I will still highly recommend to use this driver only for experimental purposes and not use it with important data.

In v18 the old bug still exists.

The directories created at the root of the mountpoint have 'Hidden' and 'System' attributes when accessed on Windows.

mount -t ntfs3 /dev/sda1 /mnt/sda1

mkdir /mnt/sda1/testdir

Then check the 'testdir' directory via Windows (e.g. Windows 7).

UPDATE: In v19 the old bug still exists.

@oech3, I don't think this will be a good idea. For many reasons.

Would you add your conf for udev,udisks to ntfs3-dkms package?

@pekmop1024, idk, the driver is at very early stage. Accordig to official FAQ they are planning to publish the source on GitHub.

Yes, we plan to publish the next releases on our GitHub: https://github.com/Paragon-Software-Group

Until than I think you can reply / email directly to the code maintainer in LKML. https://lore.kernel.org/lkml/20201106150909.1779040-1-almaz.alexandrovich@paragon-software.com/#R

@Habanishi, is there any way to send bug reports directly to Paragon developers?

Friendly reminder: until Paragon will have released/included their own fsck you'd better not uninstall ntfs-3g.

p.s. really thanks to all the good people doing benchmarks

@Hanabishi, Well, ntfs3 can't read symlinks generated in ntfs-3g, but paragon ufsd can read them.

Thank you very much.

@babam, no. Because ntfs-3g creates its own fake links, which don't work in Windows either. In fact ntfs-3g driver has poor ntfs features support and just cheats in many places.
ntfs3 creates the real native ntfs symlinks which works in Windows.

@Hanabishi,

I have symlinks that were created in the past using NTFS-3G and are now using NTFS3 and can't read them as symlinks.

Are the symlinks generated in ntfs-3g readable by ntfs3?

Can you open link.zip?

@babam, here https://i.ibb.co/26tJVdN/image.png

@Hanabishi I have created symlinks from within Linux. Can you test it $ file /path/to/symlink

@babam, it works.
The only problem is links created in Windows have incorrect path in Linux because of the separator difference (\ instead of /), or if it is absolute (like C:\).

Symbolic link doesn't work.

@galeksandrp, idk, it should work. Try to force rules reload or maybe reboot the whole system.

For anyone who encountered not working SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3" udev rule: your rule should be loaded after /usr/lib/udev/rules.d/60-*.rules. To achieve this, number in your rule filename should be 61 or higher.

Found issues (in version v8.0.0)

1. "Inode" copy not working, therefore copying file to another location on same filesystem results is real byte transfer.

@babam, using Arch + experimental patches from AUR is definitely not the best choice for stability and important data handling :)

ntfs-3g is slow but very stable and safe. I am afraid that the Paragon will destroy my important data.

found interesting bug: all folders created in Linux have system and hidden flags from Windows point of view. Tried different mount options, including no options at all, without any luck.

@pekmop1024, well, tested this with LTS, got the same error. So backporting requires source code modification.

@Hanabishi, just using LTS temporarily due to intel graphics issues in newer kernels :(

@babam, didn't tried. But I don't know in which scenario LTS users (who obviously run LTS for stability purposes) will want to apply unstable and highly experimental patches :D

@Hanabishi, Unable to build ntfs3 for Kernel 5.4 LTS?

@pekmop1024, quite expected result. The patch is very recent and was made for the latest kernel version.

Seems to be not building on latest LTS kernels:

DKMS make.log for ntfs3-5.0.0 for kernel 5.4.65-1-lts (x86_64)
Thu Sep 17 12:32:54 EEST 2020
make -C /lib/modules/5.4.65-1-lts/build M=/var/lib/dkms/ntfs3/5.0.0/build modules
make[1]: Entering directory '/usr/lib/modules/5.4.65-1-lts/build'
  CC [M]  /var/lib/dkms/ntfs3/5.0.0/build/bitfunc.o
  CC [M]  /var/lib/dkms/ntfs3/5.0.0/build/bitmap.o
/var/lib/dkms/ntfs3/5.0.0/build/bitmap.c: In function 'wnd_rescan':
/var/lib/dkms/ntfs3/5.0.0/build/bitmap.c:556:4: error: implicit declaration of function 'page_cache_readahead_unbounded' [-Werror=implicit-function-declaration]
  556 |    page_cache_readahead_unbounded(
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:266: /var/lib/dkms/ntfs3/5.0.0/build/bitmap.o] Error 1
make[1]: *** [Makefile:1729: /var/lib/dkms/ntfs3/5.0.0/build] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.4.65-1-lts/build'
make: *** [Makefile:14: all] Error 2

@timofonic, you are trying to build it on top of the previous version? Delete all files and build again.

It fails again and again...

==> Retrieving sources... -> Found 1.patch -> Found 2.patch -> Found 3.patch -> Found 4.patch -> Found 5.patch -> Found 6.patch -> Found 7.patch -> Found 8.patch -> Found Makefile.patch -> Found dkms.conf ==> Validating source files with sha512sums... 1.patch ... FAILED 2.patch ... FAILED 3.patch ... FAILED 4.patch ... FAILED 5.patch ... FAILED 6.patch ... FAILED 7.patch ... FAILED 8.patch ... FAILED Makefile.patch ... Passed dkms.conf ... Passed ==> ERROR: One or more files did not pass the validity check! error downloading sources: ntfs3-dkms

I made some test using bonnie and pts, this driver seems to be much faster than ntfs-3g

http://moodle.math.sk/~doug/bonnie_ntfs3_paragon.html

http://moodle.math.sk/~doug/bonnie_ntfs-3g.html

(disregard the read tests, since they were done from page cache)

edit: compilebench in pts, now includes native ext4, the paragon ntfs3 driver performance is comparable

https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56

@timofonic, hmm, it's ok for me. These files are downloading from an external source, maybe they became corrupted during download, try to cleanup and build again.

==> Validating source files with sha512sums... 1.patch ... Passed 2.patch ... FAILED 3.patch ... FAILED 4.patch ... FAILED 5.patch ... FAILED 6.patch ... FAILED 7.patch ... FAILED 8.patch ... FAILED Makefile.patch ... Passed dkms.conf ... Passed

Can anyone do a benchmark (Read / Write speed test) ntfs3 vs ntfs-3g.

PKGBUILD for v3
merged

@Hanabishi, Thanks.

And there has released ntfs3 v3

https://www.phoronix.com/scan.php?page=news_item&px=Paragon-NTFS3-V3-For-Linux

https://lore.kernel.org/lkml/20200828143938.102889-1-almaz.alexandrovich@paragon-software.com/

@babam yes. Don't forget to install linux-headers package first.

Is working on the latest kernel?

Thanks you for the hint!

Requires explicit fs type to mount (-t ntfs3).
If you want to use ntfs3 as the default driver, such udev rule does the trick:

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"

Performance tips:
noatime option can speed up filesystem operations.
prealloc option reduces disk fragmentation (useful for HDD).

Another hint for udisks. Add a such options to /etc/udisks2/mount_options.conf in [defaults] section:

ntfs3_defaults=uid=$UID,gid=$GID,noatime,prealloc
ntfs3_allow=uid=$UID,gid=$GID,umask,dmask,fmask,iocharset,nohidden,sys_immutable,discard,force,sparse,showmeta,prealloc,noacsrules,acl