
NTFS read-write GPL kernel driver - ButSpider
https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d74@paragon-software.com/
======
KindOne
Discussion on reddit:

[https://www.reddit.com/r/linux/comments/i9mdqg/ntfs_readwrit...](https://www.reddit.com/r/linux/comments/i9mdqg/ntfs_readwrite_driver_gpl_implementation_by/)

When exFAT was announced about 5 months ago Paragon Software posted a rant
against that.

Rant is posted here:

[https://news.ycombinator.com/item?id=22688058](https://news.ycombinator.com/item?id=22688058)

~~~
tomc1985
Paragon, purveyors of fine commercial filesystem drivers that corrupt my hard
drives? LOL

~~~
mehrdadn
It's easy to laugh at them but I've had corruptions from Linux's existing NTFS
implementation too.

~~~
tomc1985
I've had issues with their Windows HFS+ driver too, shit wiped out a hard
drive that I later learned wasn't fully backed up

~~~
mehrdada
+1 had the same issue with their HFS+ driver, and it did not take that long to
encounter it.

------
ufmace
Everyone (on Reddit at least) seems to be yakking away at whether Paragon
Software is good or bad and what other things they've done. I just wanna know
if this driver is actually good or bad. Far as I know, a Linux NTFS driver
capable of writing has been a long time coming.

~~~
lizknope
I've been writing to NTFS for at least 10 years. It was the FUSE driver but it
worked fine and I never had any problem other than it seemed to write at half
the speed of ext4

~~~
speedgoose
NTFS is super slow on windows too. You get better performances with ext4 on
WSL2 (Windows Subsystem for Linux).

~~~
risho
how is this possible? isn't wsl 2 literally a virtual machine image on top of
your ntfs drive?

~~~
neurostimulant
I think it bypassed windows filesystem filters (antivirus, etc) and thus
faster because there is nothing taxing your read/write operations.

~~~
tfigment
It least with WSL1 I know that McShield and cyvera/Traps are fully capable of
massively interfering with linux performance under windows 10 just like they
do normally. Whether they actually effective is not something I know but it
seems like they understand ELF files.

------
loeg
Beware, it does not seem functional:
[https://lore.kernel.org/lkml/87h7t5454n.fsf@suse.com/](https://lore.kernel.org/lkml/87h7t5454n.fsf@suse.com/)

------
m000
Any guesses why Paragon decided to GPL the driver now?

~~~
CameronNemo
They didn't. Samsung wrote this driver and Microsoft proposed its inclusion
into the kernel.

~~~
rwmj
Are you thinking about exFAT?

~~~
CameronNemo
Yep. My bad.

------
pengaru
Does anyone really care anymore since ntfs-3g works well enough?

~~~
nitrogen
I haven't checked in a really long time, but years ago ntfs-3g had a really
suboptimal allocation pattern for spinning drives, and optimizations were only
present in the commercial version. I don't know if the block allocation
strategy was owned by ntfs-3g or if it was using something in-kernel.

If I'm remembering the details right (and that's a _big_ if), large files
written sequentially would have their blocks scattered all over the place,
making e.g. large uncompressed videos written from Linux too slow to play due
to seek times, when if they'd been written sequentially they would have been
fine.

~~~
pengaru
ntfs-3g is entirely implemented in userspace, and is far more trivial to hack
on and test if anyone wanted to improve its file allocation strategies than an
in-kernel driver would be.

Years ago when working on a commercial virtualization product I had to support
initializing sparsely populated ntfs filesystems where only the filesystem
metadata was written out, with allocated file extent ranges logged externally
and not actually populated in the sparse ntfs filesystem in a file. I ended up
deriving a small library for doing this from the libntfs-3g code, I don't
think it took more than a weekend to do, the code was quite sane.

What I recall from that experience was that the file extent allocations on an
empty filesystem was perfectly efficient, since you'd have to go out of your
way to make it bad.

The real trouble was when the filesystem was used enough for its free space to
become fragmented. At that point the allocation strategy was quite poor and
you would end up with extremely fragmented large files. IIRC it was really
just a naive sequential find first free blocks kind of thing. This aspect is
consistent with your memory.

I think if we wanted to improve that aspect of linux ntfs support we're better
off working from ntfs-3g.

Not to mention there are some significant down sides to in-kernel filesystem
drivers, they are rather problematic when it comes to containers/namespaces
and the security story is a total shit show.

------
alexeiz
I don't know about Paragon's NTFS driver for Linux, but their non-free Ext4
driver for Windows had a nasty bug until recently, where it would change file
ownership and permissions in the filesystem mounted in read-only mode,
rendering the driver unusable. The bug apparently got fixed after numerous
complaints on their support forum, but I still use this driver very cautiously
and only when I have to.

So I wouldn't trust Paragon's claim of "decades of expertise in commercial
file systems development and huge test coverage."

------
rbanffy
I haven't used a dual boot Linux/Windows machine in ages. How popular is this
setting these days?

On Linux, my most common scenario of deploying Windows is in small VMs and,
when needed, mounting host folders from them. It's true these VMs will
probably not run some PC software well, but I have a Windows PC for that. The
other way around we have WSL and WSL2 on Windows, again kind of erasing the
need to dual boot from the Windows user side.

The money for them here is in support. Maybe they have licensees that bind
them to support contracts and merging software into mainline Linux counts as a
"best effort" to make others chip in at keeping it functional as the kernel
evolves.

~~~
loeg
I haven't dual-booted in ages, but sometimes use NTFS for USB drives or
inspecting drive images from Windows machines / VM guests.

~~~
Macha
I used to do this in my college days. Had some work (Unity projects
especially) that would run into FAT32 file size limits and NTFS was the one
more advanced filesystem that at least somewhat worked on all three OSes,
albeit read only on OS X. exFAT support for Linux didn't exist at the time and
FAT32, exFAT and NTFS are still the only three OS portable filesystems.
Windows cannot handle HFS+/APFS, ext* is not supported on Mac and poorly
supported by third party software on Windows, and ZFS/btrfs/XFS/UFS/etc are
out of the question for both Windows and Mac.

~~~
loeg
Amusingly, there was actually a historical Mac ZFS effort that was, I think,
sidelined in favor of APFL: [https://arstechnica.com/gadgets/2016/06/zfs-the-
other-new-ap...](https://arstechnica.com/gadgets/2016/06/zfs-the-other-new-
apple-file-system-that-almost-was-until-it-wasnt/)

They had a GPT GUID for it: 6a898cc3-1dd2-11b2-99a6-080020736631.

~~~
rbanffy
Time Machine looks like it was designed for ZFS and some poor engineer at
Apple had to graft it on top of HFS.

------
Zardoz84
Perhaps I'm confused, but we not had a NTFS r/W driver working since many
years ago ?

~~~
marcosdumay
There is a userspace driver with rw capability, and a kernel driver that only
supports ro.

------
gigatexal
Given the initial testing people on the mailing list have done and the issues
that have arisen I hope the kernel maintainers so f no and push back until
said issues are fixed and code quality rises.

------
mPReDiToR
Was there something terrible about NTFS-3G?

~~~
m000
Uhhhmmm... Speed? Stability? NTFS-3G has been a lifesaver for occasional use,
but with anything remotely I/O intensive, it starts to crack.

~~~
krzyk
Why would you use NTFS on linux for anything other than occasional use?

~~~
nicoburns
It's the only non-FAT filesystem with good cross-OS compatibiity.

~~~
m000
This. Now, you've made me wonder if in the near future you could have both
Windows and Linux installed on the same _-gasp-_ partition.

~~~
brnt
I had for years. Usung Wubi.

------
ilkkao
Has this been merged already?

~~~
the8472
It was posted yesterday and the replies indicate issues with the patch. So as
these things usually go it'll probably take a long time until it's ready for
inclusion.

------
sam_lowry_
Argh, Russian hackers, again!

------
0x0
Bad line-wrapping in the first commitmsg does not leave a first good
impression.

------
xvilka
Good news because NTFS-3G seems dead - last update[1] was in 2017. Moreover,
quality of the code is far from perfect.

[1]
[https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tg...](https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tgz)

