The New NTFS File-System Driver Has Been Submitted For Linux 5.15

[ruthan]

When it would be able to boot Linux form NTFS partition to get rid of Linux specific filesystems? NTFS would be nice for multiboot.

[oiaohm]

Over 10 000 games, not 1000. Not a single problem so far.

Do note the one about a few where its a cut seen or something else part way though. The problem is the so far bit. It takes quite a bit of time to be sure with wine that there is not hidden devils.

[mozo]

Sorry 1000 of games is still a drop. There are different feature wine uses that can still catch you. One game you will have to play at least hour into game before your save dies and you being unable to complete the game and its due to a file system feature missing resulting in a cut seen video not working. The new driver is well head of ntfs-3g in feature implemented but its still not the complete list wine will use.

Please note wine will run with missing file system features as long as the application/game does not use them. So wine prefix on ntfs with the new driver is still a high risk of opps my program died due to file system at some random point than ext4 or xfs. If you are willing to take the risk that is fine.

If you are after low risk loop back file of ext4/xfs on the ntfs partition using the new driver in most cases will have enough performance for most games with wine. This was not the case with ntfs-3g fuse.

Over 10 000 games, not 1000. Not a single problem so far.

[oiaohm]

What issue? I tried then of thousands games on NTFS with Wine - no problems at all.

Sorry 1000 of games is still a drop. There are different feature wine uses that can still catch you. One game you will have to play at least hour into game before your save dies and you being unable to complete the game and its due to a file system feature missing resulting in a cut seen video not working. The new driver is well head of ntfs-3g in feature implemented but its still not the complete list wine will use.

Please note wine will run with missing file system features as long as the application/game does not use them. So wine prefix on ntfs with the new driver is still a high risk of opps my program died due to file system at some random point than ext4 or xfs. If you are willing to take the risk that is fine.

If you are after low risk loop back file of ext4/xfs on the ntfs partition using the new driver in most cases will have enough performance for most games with wine. This was not the case with ntfs-3g fuse.

[mozo]

I wonder if this new driver can solve the wine issue when creating a wineprefix on an NTFS unit. Most likely not, as it's NTFS fault for not having a permission system. But would be cool.

What issue? I tried ten of thousands games on NTFS with Wine - no problems at all.

[oiaohm]

I wonder if this new driver can solve the wine issue when creating a wineprefix on an NTFS unit. Most likely not, as it's NTFS fault for not having a permission system. But would be cool.

The new ntfs driver still does not contain all functionality that wine wants. It does contain more than ntfs-3g so better chance of not completely exploding in one face. Performs better for a loop back ext4 or xfs on ntfs partition.

The issues are not just permission system.

https://wiki.winehq.org/FAQ#Does_Wine_run_on_all_Unix_filesystems.3F

Yes the ntfs3 solution biggest problem is in fact it was missing mapping files from disc to memory that wine uses a hell lot of. This may have changed since that was written in the faq but if the new ntfs driver in kernel still has that problem you are absolutely in hell attempt a wine prefix on it.

There are a lot of features that wine uses that are not permission based that still need the file system driver to support them. Note I said file system driver not the file system design being the on disc bit. Lot of these feature really have nothing todo with what is on disc (like permissions and so on) but how completely coded the file system driver is with Linux or freebsd.

[Zeioth]

I wonder if this new driver can solve the wine issue when creating a wineprefix on an NTFS unit. Most likely not, as it's NTFS fault for not having a permission system. But would be cool.

[oiaohm]

Most people exchange flash drives and other removable storage with people who use other OSes. Many people also use multiple OSes.

And when you start doing that you might start with NTFS these days but after awhile and quite a few ntfs failure latter you will be switching to exfat.

Thing to remember multi windows computers alone can screw you over using ntfs on a removable flash drive. exfat lacks the ability for windows to record permissions this is one of the factors why it works better for windows than ntfs as a transfer drive.

https://www.pcworld.com/article/3109559/why-your-usb-drives-file-format-matters-fat32-vs-exfat-vs-ntfs.html

The recommendation in the many OS case has been exfat if possible followed by vfat then finally followed by NTFS as last option for quite some time for removal storage.

NTFS is only really if you are usb key between computers connected to the same active directory setup and the machines are windows. Then you have to ask the question why not use a network share(there are cases where the answer is speed usb key will be faster).

NTFS support is more important to Linux for migration than USB flash drives and other removable storage. NTFS is not designed for removable storage and windows does not handle ntfs correct for removable storage moving across systems owning to different domains of permission.

[insilications]

polarathene This patch collection seems to be a byproduct of the custom kernel the repo owner spins for the Archlinux AUR and he has also created custom code & tweaks for this project aswell (ll, lucjan).

When you look into the README.md you can see where the patches are coming from. They are formatted in a way that you can selectively add specific features/fixes/patches of i.e. -pf, -ck, …, or archlinux kernels to a vanilla kernel.org sourcetree. A bit more information can be found on the author's gitlab here and here.

The patches are mostly organized as diffs between the stable kernel releases (5.13, 5.14, etc.) and the develoment branches of the custom kernel projects (linux-next, ProjectC, linux-pf,… the sources mentioned in the readme). LTS versions may get updated patchsets (feature backports) via this repo for longer aswell. You can get them merged into one file to avoid clutter or separately (-sep) if you want to cherry pick for yourself.

Since these development projects (like the ntfs patches or fixes from linux-next) do get updated several times during the lifetime of a stable kernel version or a minor release (i.e. 5.13.X) can make some of the patches obsolete, there are different versions of these patchsets (i.e. ntfs-patches-v1, -v2, -v3 and so on) aswell.

Another reason why old versions of the patchsets are still kept there is that stuff might break or not work as expected (they're mostly using out-of-tree code or stuff that hasn't hit linux-stable, afterall) and it allows you to revert to an earlier version.

Further you can get, say, an AIO patch containing the latest ProjectC version & dev-branch fixes without having to wait for Alfred to publish a new release as an all-in-one-patch. Be aware that lucjan structured the ProjectC patches differently than Alfred to allow for getting new features in older kernel versions (i.e. prjc-5.14 patchset in 5.13 kernels), meaning that they're incremental updates (require previous -v to be merged aswell), which is not the case for i.e. the ntfs and zstd patches.

Alternatively, you can also get the original PDS patches (from before ProjectC) and apply them to a recent kernel. For older kernels, there are also the original BMQ patches. That's the reason why they're listed separately from each other. The original PDS patchset is what was formerly known as "undead PDS" or PDS-mq and was offered a long time for TKglitch custom kernels.

The lru patches might be interesting for some very specific users as they are used to build realtime-capable (fully preemptible w/ latency guarantees) kernels.

My picked the following patches: I used this repo to get some of the XFS and memory management fixes expected to land with linux-5.15 even before 5.14 stable was released, got a feature that preserves some more memory pages to avoid UI stalling when I use up all my RAM when compiling big stuff, some more block device tuning for SSDs and lower CPU utilization under heavy IO, a security tweak + other misc. stuff like more complete zstd support within the kernel. Then I added ProjectC from Alfred's gitlab (for which I may get updates from lucjan, should I want to stay on 5.13), pulled futex, fsync2 and winesync patches from TKglitch's repo for better Proton support and got the patch for generating cpu-specific optimized kernel code from graysky for a general performance boost.

I hope this answered your questions to a satisfying degree, cheers.

Amazing explanation. Gonna test the mm fixes, especially the one that protects pages from running software. Also XFS and other bits.

[jacob]

You say:
1. majority uses Windows
2. everyone else needs to mount Windows filesystems every now and then

Sorry but you contradict yourself. Why would everyone else, who doesn't run Windows, need to mount Windows filesystems?
I don't have any Windows machine at home, why would I need Windows filesystem browsing ability?

"some - like you - are members of a cult that makes life more complicated for themselves for no reason at all"
How do I complicate life for myself, by not running Windows or by not having any Windows filesystem? For me that's actually very easy life, not needing to interchange between filesystems.

Most people exchange flash drives and other removable storage with people who use other OSes. Many people also use multiple OSes.