How to bring NTFS3 from Kernel 5.15 to Linux Mint?

[Michael_Hathaway]

How fast is NTFS3 vs ext4?

[rene]

How fast is NTFS3 vs ext4?

My expectation until we see (I already looked for a Phoronix article on that yesterday but it seems to not yet exist...) data is that this would by and large be "on par".

[t42]

I trust that if you do the same rm -f file && touch file && sleep 5 && touch file dance that stat -c '%w, %x, %y, %z' file will indeed show that 5 second difference. I.e., trust that statx() will finally be functional with coreutils 8.32.

Just as expected

Code: Select all

stat -c '%w, %x, %y, %z' file
2021-11-04 06:10:58.280794437 +0100, 2021-11-04 06:11:03.308760062 +0100, 2021-11-04 06:11:03.308760062 +0100, 2021-11-04 06:11:03.308760062 +0100

Also with NTFS partitions available but no Windows at hand I can't test USN Journal logging [highly improbable] implementation in ntfs3.
USN entry line in USN journal after Linux operation is always a zero, like

Code: Select all

fsutil usn readdata "h:\###\linux.txt
Major Version    : 0x3
Minor Version    : 0x0
FileRef#         : 0x00000000000000000003000000002e45
Parent FileRef#  : 0x00000000000000000003000000002e3d
Usn              : 0x0000000000000000

vs Windows one:

Code: Select all

fsutil usn readdata "h:\###\171022-1543=windows.txt
Major Version    : 0x3
Minor Version    : 0x0
FileRef#         : 0x00000000000000000003000000002e37
Parent FileRef#  : 0x00000000000000000003000000002e3d
Usn              : 0x00000000000020e0

[rene]

Thanks much for confirming; shall get ready to transfer my "btime tags" on the .flac collection back into the fs proper...

Had to google what USN even was; use Windows on one system as a game-launcher, on some other systems "since it's licensed" and as a firmware update tool in some far off corner of a secondary disk --- and am not a storage-nerd in the first place. Feel it highly interesting to use a filesystem that won't regularly eat data I in fact care about but that's about as far as my technical interest goes I must say. But it is as a matter of the more general technology interesting to see how badly NTFS-3G performed (in the real-time, modulo sync) sense in comparison; it was always going to be bad what with the many round-trips between kernel- and userspace but a factor 7 on that kernel-source unpack; I was as said ready for 3...

[DareDevil73]

I would inform who maybe interested in, that I have added the supporto for NTFS3 (along the UFSD) to my https://github.com/antonio-petricca/buddy-linux project.

[therob]

Hey. I think now I (=OP) want to try to install 5.15 manually via PPA as you suggested. Before doing this I have some further question to be on the safe side:

• So easiest/safest way is to add the PPA to my system as stated here, refresh update cache and now the question:
  1. manually install 5.15 via sudo apt-get install linux-generic-5.15
  2. or will there be automatically a new update entry in "mintUpdate" App of the kernel to 5.15 (and later on always the most recent)?
• Will there also be updates of any firmwares/drivers outside the kernel (I am not that familiar how it works)?
• If I want to revert everything I can either boot with the old Kernel via GRUB-options or I can remove the PPA and deinstall 5.15 manually to go back to old Kernel, right?
• should I expect any drawbacks or compatibility issues (guess depending on my hardware)? You mentioned already NVidia driver - but since I just use the driver out-of-the-LM-box I do nothing fancy with graphic on my Apsire E5-575G-Notebook - and should be fine here, right?
• after successful installation I have to change the mount option in /etc/fstab from:
  1. ntfs-3g defaults,windows_names,locale=de_DE.utf8,uid=1000,gid=1000 0 0 to
  2. NTFS3 defaults,windows_names,locale=de_DE.utf8,uid=1000,gid=1000 0 0 - or should it be any different as any of the options changed or are not neccessary anymore? [--> see following edit]
  3. edit: this is now working: ntfs3 iocharset=utf8,uid=1000,gid=1000 0 0
• anything else to consider?

[rene]

I will first of all mention that I have by now reproduced t42's benchmark: on a Core i7 2.8G with 8G RAM, an empty 2T NTFS filesystem on an HDD (i.e., a spinner) and with the 5.15 kernel sources as obtained from https://cdn.kernel.org/pub/linux/kernel ... .15.tar.xz, unpacking onto said fs with

Code: Select all

tar xJf /some/where/else/linux-5.15.tar.xz && sync

with old NTFS-3G takes consistently ~ 3m15s real-time and with new NTFS3 consistently ~ 30s; a factor 6.5. I note that this is total time including the sync whereas t42 saw that factor without sync; I expect this to be the result of HDD vs. SSD; don't currently have enough SSD-space to test. A slower or faster CPU also still matters with .xz and less than 8G RAM would supposedly also. But: a factor 6.5, then; nice.

Yes, that tuxinvader PPA is the way to go now that Ubuntu's own mainline PPA has introduced a 20.04 LTS incompatibility.

Code: Select all

$ sudo add-apt-repository ppa:tuxinvader/lts-mainline
$ sudo apt-get update
$ sudo apt-get install linux-generic-5.15

Note again and also for others that the above is an unsigned kernel; that you if you were to use binary drivers such as "nvidia" want to disable secure boot in your BIOS or switch to the open-source "nouveau" driver first.

Reverting is a simple matter of rebooting into the Grub menu and booting with a different kernel, then running

Code: Select all

$ sudo apt-get purge --autoremove "linux-*-5.15-*"

There will not be any automatic firmware updates but you don't need any. If you have custom kernel drivers installed into the DKMS system they will be recompiled and reinstalled automatically. You should not expect an issue but of course proof/pudding/eat.

Yes, you have to change the filesystem type in /etc/fstab from ntfs or ntfs-3g to ntfs3 (lowercase). Neither windows_names nor locale are by ntfs3 supported mount options and it does allow to create with Windows incompatible filenames: "so don't do that then"; locale was also with ntfs-3g a deprecated option and should supposedly not matter. Please change /etc/fstab prior to reboot: systemd parses the file only at bootup unless you manually intervene.

A warning; if you as to those mount options hit upon e.g. https://git.kernel.org/pub/scm/linux/ke ... st?h=v5.15 where it says that the discard option is "recommended for use with SSDs" then please ignore that: discard is continuous TRIM and kills any performance at least on deletes; on Mint a by default weekly fstrim run is used instead.

[t42]

I will first of all mention that I have by now reproduced t42's benchmark: on a Core i7 2.8G with 8G RAM, an empty 2T NTFS filesystem on an HDD (i.e., a spinner) and with the 5.15 kernel sources as obtained from https://cdn.kernel.org/pub/linux/kernel ... .15.tar.xz, unpacking onto said fs with

To provide more data I tested the above on the Ryzen 5 5600, RAM 32GB DDR4 and x4 SSD (writing ext4 10GB file per1800 MB/s)
My previous test was on AMD FX-4320 Bulldozer CPU, RAM 16 GB and SATA3 drive

Code: Select all

ntfs3
time tar -xJf /media/ramdisk/linux-5.15.tar.xz && time sync

real	0m6,760s
user	0m6,336s
sys	0m3,469s

real	0m0,770s
user	0m0,005s
sys	0m0,000s

Code: Select all

ntfs-3g
time tar -xJf /media/ramdisk/linux-5.15.tar.xz && time sync

real	0m17,002s
user	0m8,292s
sys	0m6,243s

real	0m0,333s
user	0m0,001s
sys	0m0,000s

[rene]

That's a fair bit faster than the 3m15s / 30s on my 2010-era WD Black spinner... and makes sense that for NVMe the factor would go down I guess: especially at larger queue depths (threads, in the firmware sense) the 4K Random Write IOPS for an NVMe drive are much higher than for a SATA one. For example for a Samsung 870 EVO vs. a 970 EVO, at queue depth 32 it is ~ 90K vs 400K:

https://www.samsung.com/semiconductor/m ... er/870evo/
https://www.samsung.com/semiconductor/m ... er/970evo/

(although I'm admittedly not too sure if "random" writes are the best thing to look at here; the Linux kernel supposedly does a fair job of bunching things up sequentially on that single unpack of a source tree)

Anyway; I should stop caring since I'm extremely uninterested in NTFS --- but technically it's still fairly fascinating. Thanks for testing...

[rene]

Oh, by the way, let me also mention that I saw a tremendous difference unpacking to the 35% full 100G /windows/c and the empty 1.9T /windows/d on that 2T spinner (it's a 5th drive that's in there for the heck of it and since I have a Windows 7 license for the dumb thing anyway...); former was at least with NTFS-3G and when newly mounted só ridiculously slow that I didn't even bother testing further. Might as such also be necessary to specify empty or not as to the NTFS filesystem the tree is unpacked to.

[t42]

My last test on Samsung SSD 980 was on two empty test partitions created with GParted and mounted with two fstab entries.
I thought a difference between sync of our SATA tests (SATA3) may be due to the fragmentation of my drive.

[therob]

OK, I made it thanks to you guys. But some questions remain...

• after the first reboot GRUB took me directly to the old kernel; I had to reboot a second time to manually choose the 5.15 in the grub menu. Have to find a way to make it automatically. With GRUB Customizer the first main entry indeed points to the old kernel. Why this was not changed by the installation script? Interestingly I just noticed that the "main entry" points to 5.4.0-81 although I see in the submenu that also v84,86,88,89 which I installed via normal system updates before and now 5.15. But why the main entry is resting at 81? How to solve (in an automatically manner, thus also for future updates)?
• I now changed NTFS3 options in fstab to ntfs3 iocharset=utf8,uid=1000,gid=1000 0 0 and everything seems to work (partition is mounted correctly, also the special characters are handled fine thanks to the utf8 option). I checked options here.
• now my main point: finally I can see the "creation date" of my files - that's good!! BUT noticed some uggly behaviour (all just checked with nemo 5.0.5, but not in terminal):
  • files which I now create freshly using NTFS3 and save again one minute later have correctly different times for "creation" and "last changed", differ for one minute as expected.
  • files I formerly created with NTGS-3G and now reopen and resave with NTFS3 DO NOT PRESERVE the creation date during save - instead both (creation and last changed and also last accessed) are set to the date of the last change. Thats not OK. Also if I copy a file which shows this behaviour but using NTFS3 for copy now shows afterwards the same odd behavoiur. How to solve?
  • files, which I created using windows 10 long time before, didn't touch with NTFS-3G but now resave with NTFS3 also correctly preserve creation date and just updates the "last changed" as expected.
  • just noticed another uggly thing: I had difficulties to create/save files in certain folders of the ntfs3-mounted device ... I now made some changes in the permission rights and now it works again (but I don't know why it is neccassary and if I did not made something stupid ... any thing I should recheck now?)
• If I now plug-in my external USB-backup-drive with NTFS-partition it seems to still mount with NTFS-3G (see quote below), and I can't see/access the creation dates there.

  The automounter will not automatically use ntfs3, and last time I checked was on our version of udisks still hardcoded so "can not" for now be updated in a supported manner.

  How to solve this? Because if I can't solve it, I can't do my backups correctly :-/ Work-around could be to also make a fstab entry for the backup-drive, but I think it will end in an error message if the device is not plugged-in (as it is most of the time not), or better ideas?
• How I now have to update the kernel in the 5.15+ line? Will it show up in mintUpdate (which I use regularly), as it did before for the 5.4.0-line?

Hope you can bring me the way down til the end Thanks!

[t42]

[*] after the first reboot GRUB took me directly to the old kernel; I had to reboot a second time to manually choose the 5.15 in the grub menu. Have to find a way to make it automatically. With GRUB Customizer the first main entry indeed points to the old kernel. Why this was not changed by the installation script? Interestingly I just noticed that the "main entry" points to 5.4.0-81 although I see in the submenu that also v84,86,88,89 which I installed via normal system updates before and now 5.15. But why the main entry is resting at 81? How to solve (in an automatically manner, thus also for future updates)?

You have GRUB Customizer installed and it is a root of evil. Even after purging it's hard to remove consequences without creative efforts.

Sorry I can't comment on other things without guessing as there is no Windows here and almost all storage was migrated to ext4.

How I now have to update the kernel in the 5.15+ line? Will it show up in mintUpdate (which I use regularly), as it did before for the 5.4.0-line?

You will see new version in Linux Kernels module of the Update Manager.

If I now plug-in my external USB-backup-drive with NTFS-partition it seems to still mount with NTFS-3G (see quote below), and I can't see/access the creation dates there.

"udisks still hardcoded" ... but if ntfs-3g is not installed? What is cat /proc/self/mountinfo |grep ntfs for such drive.
I personally have a line in fstab for such drives with the noauto option.

checking hardcoded: nodev, nosuid, uhelper=udisks2 and cannot be overrided.
why not insert in udisks2.conf something like

Code: Select all

[defaults]
ntfs3_defaults=uid=$UID,gid=$GID
ntfs3_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case

[therob]

What is cat /proc/self/mountinfo |grep ntfs for such drive.

without any further changes for my external NTFS-Drive it is:
1046 31 8:17 / /media/xyz rw,nosuid,nodev,relatime shared:514 - fuseblk /dev/sdb1 rw,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096

[t42]

I see. just try noauto in fstab

[rene]

Yes, the boot version thing would seem the result of having/using Grub Customizer; normally the highest version is booted into automatically; will leave up to you to undo whatever it is that got done.

As to the behaviour of btime/crtime on existing NTFS-3G-created files vs. new NTF3 ones I see that NTFS-3G used to keep crtime in a so-called Extended Attribute so as to work around non-native support on UNIX. I'm afraid it's too much of an NTFS specific issue for me to want to go check how e.g. something like a graphical file manager gets and/or sets a creation time timestamp on NTFS; am myself interested neither in NTFS nor graphical file managers really, and especially since they now as a matter of at least the GNU coreutils version on Mint 20.x don't Just Work (Sanely/Transparently) even for a Linux native filesystem such as ext4 I would say you're just a bit too quick to the party to have this all behave OOTB. Pardon then, but also good luck with that one

Yes, you'd for at least now want to add a "noauto" /etc/fstab line for your NTFS filesystems. I.e., if we assume that with the device(s) connected one such NTFS filesystem in the output of blkid shows as

Code: Select all

/dev/sdz99: UUID="0123456789ABCDEF" TYPE="ntfs" PARTUUID="..."

you'd e.g. sudo mkdir /mnt/foo and create a line in /etc/fstab such as

Code: Select all

UUID=0123456789ABCDEF	/mnt/foo	ntfs3	noauto,noexec,fmask=133,dmask=022,gid=therob,uid=therob,iocharset=utf8

and would find that after reboot or systemctl daemon-reload && systemctl restart local-fs.target the automounter would mount the FS with that UUID on /mnt/foo and with those options (by the way not sure that you need the iocharset one, but anyways). It'll probably Just Work in some future version of our userlands --- but not our current ones.

Since you installed linux-generic-5.15 rather than more explicitly e.g. linux-image-unsigned-5.15-051500-generic you'd get updates "tuxinvader" makes to that 5.15 series automatically. Which is not to say that I would expect them to make (m)any; you are again very quick to the party here and are for a very large part on your own until distributions catch up to e.g. 5.15 and ntfs3.

[t42]

Just installed Ubuntu 20.10. It has coreutils 8.32-4ubuntu2 and it is possible for 20.10 to install kernels from Ubuntu's mainline ppa kernel-ppa/mainline/v5.15/amd64

Partitions mounted with ntfs3 behave as expected

Code: Select all

rm -f file && touch file && sleep 5 && touch file
stat -c '%w, %x, %y, %z' file
2021-11-09 11:52:04.682441600 +0100, 2021-11-09 11:52:09.686652200 +0100, 2021-11-09 11:52:09.686652200 +0100, 2021-11-09 11:52:09.686652200 +0100

Maybe there is a small chance OP will be interested in it. It took me more then hour to bring a system to acceptable for me state of Gnome 40 desktop, software and other settings.

[t42]

wrong quote, sorry

[therob]

I now have running 5.15.1-051501-generic for 3 days as daily driver.
I fixed start-up problem by manually change the command via GrubCustomizer (will for now do it also for further updates and have later a look at it).
The external drive mount with ntfs3 now also works (thanks to using your suggestion noauto,noexec in /etc/fstab). Now uses ntfs3 (checked with cat /proc/self/mountinfo |grep ntfs)

But 2 things are not as expected:

• Using stand-by/sleep at the moment a little bit kind of lottery: some time (seconds? minutes?) after a fresh boot stand-by/sleep is working as expected (suspended to ram and waking up within 1 second) that's how it was al fine with the old kernel, never a problem there. But starting from an (for me still unknown) point in time sending notebook to sleep behaves strange - after beeing in sleep notebook is coming back to normal just after 1 second (display flickers 2 times, WiFi needs to reconnect - so it seems that sleep was reached, but just for <1second). Also once followed by a freeze/crash of system.
• Shutdown of system normally goes very fast (<5seconds), just shortly some lines of code, the circling LM-logo and off. But now with 5.15 after this the LM-Logo reappers and stays there for another 5-10 seconds before shutting off.

Could you see this in clear connection with 5.15? Do you think I can do anything about this - or ist the answer in this case just "you are to early with 5.15 for the LM-ecosystem"?

Thanks for some ideas. I would like to stick with 5.15.

Side question: The MintUpdater showed my already one update of 5.15 which worked fine, but yesterday also a update of my old kernel 5.4.0.-xx ... here I was uncertain, if I should make this update (I think I should, because it should let the 5.15 installation untouched, right?)

[t42]

The automounter will not automatically use ntfs3, and last time I checked was on our version of udisks still hardcoded so "can not" for now be updated in a supported manner.

Still in is possible to mount 'ad hoc' external device with ntfs3
[1]
- disable auto-mount and connect the device (or eject the partition if already connected)
[2]

Code: Select all

 - udisksctl mount -b /dev/sdXY -t ntfs3
Mounted /dev/sdXY at /media/USER/Apacer_XYZ

Code: Select all

mount |grep /dev/sdXY
/dev/sdXY on /media/USER/Apacer_XYZ type ntfs3 (rw,nosuid,nodev,relatime,uid=0,gid=0,iocharset=utf8,uhelper=udisks2)