Paragon submits 27k-line NTFS driver to Linux kernel

https://www.theregister.com/2020/08/18/paragon_tries_to_contribute_ntfs/

by kiyanwang • 6 years ago

203 149 6 years ago

theregister.com

mariuolo• 6 years ago

I don't think it's completely fair.

Don't look a gift horse in the mouth, especially when you need one.

Pick-A-Hill2019• 6 years ago

I think their (the kernel maintainers’) position is that a single patch of 27000 lines of diffs is a bit of a nightmare to do code review on. I’m not sure if you took a look at the patch file (available at https://dl.paragon-software.com/ntfs3/ntfs3.patch ).

I think their point is ‘man, how are we going to divide this up amongst the maintainers? Who gets to check which function or call?’

Paragons response (more or less will fix in v2) https://lore.kernel.org/linux-fsdevel/a8fa5b2b31b349f2858306...

tyingq2• 6 years ago

Using language like "monstrosity" though, doesn't help.

dboreham• 6 years ago

If it's working code (assume it is) then requiring it to be turd-polished for the purposes of code review is absurd. Whoever is asking for that is either disingenuous or has no real experience as a software developer.

znpy3• 6 years ago

On one hand yes, on the other hand if you want your patch to be included it's your job to make it reviewable and to make it pass all the various checks.

After all, we all lived long enough without their software, we can live without it a bit longer.

Yes it's a gift, but it's also code that has to be maintained and updated along with the kernel, so it's not really 100% a gift. If you then consider that they might keep on selling a proprietary version of the code (which - don't get me wrong - is 100% legit and fair) they might also get basically free labour: they could rebase onto the latest public gpl version, they might get notes of various issues and bugs...

Quite literally, it's free labour.

hinkley2• 6 years ago

“Free as in puppy.”

cratermoon2• 6 years ago

f you want your patch to be included it's your job to make it reviewable

I have a mid-junior level co-worker who submits PRs that are excessively large. As best I've been able to determine, he's not especially good at managing the dependencies in his code, and he doesn't want to submit a broken PR, so his default is to wait until he gets everything written instead of breaking it down into smaller pieces.

rhn_mk1• 6 years ago

Taking up patches to code is also taking up vulnerabilities and bugs they carry. Even assuming good intentions, a gift of code is a gift with a burden attached, and should pass deep scrutiny before getting accepted.

Sad as it may sound, free code doesn't come for free.

mason55• 6 years ago

This is like giving someone a litter of puppies as a gift and then walking away.

Hooray, free puppies. Now you just have to care for them for the next 10 years.

setr2• 6 years ago

Paragon stated their intent to maintain and support the code in their initial email, and added themselves to the maintainer files.

There's no drama happening here. Paragon guys are trying to give it "properly", and linux guys want it "properly", and the only thing happening is defining "proper" in this context

eirini1• 6 years ago

how is that a good comparison, when you're given puppies you are being made responsible for living creatures, If you're given a bunch of code you can literally just drop it.

mixmastamyk• 6 years ago

Someone else mentioned their commitment.

Additionally, the driver is mature, as is the FS.

guenthert• 6 years ago

Working on someone else's code is no fun. I do it, when I get paid properly, but can't say I enjoy it. So I understand that not everyone is enthusiastic about that gift.

And who needs it? There are alternatives to read or write the occasional file (e.g. if you happen to have forgotten the Admin's password) of a NT box, but I can't say that I missed the ability to create new files in a NTFS. And why now? Surely those who actually needed that functionality, needed it years ago and meanwhile found some other solution. Perhaps those who actually need it still volunteer to ready that driver for inclusion into the kernel or sponsor someone who can?

formerly_proven2• 6 years ago

NTFS-3g can create files and directories etc. on NTFS (albeit it doesn't do journaling, that's why it requires you to have a clean journal). Having a proper kernel driver is mostly about performance, not features. The current built-in kernel driver for NTFS is completely read-only though.

krisoft• 6 years ago

"Don't look a gift horse in the mouth"

Interesting you choose that metaphor. I can think of a particular gift horse where you would have seen Greek soldiers if you have looked into its mouth. :)

toyg6• 6 years ago

especially when you need one.

It's very debatable that Linux "needs" more support for a proprietary 25-year-old filesystem that is, in many ways, obsolete.

DHowett• 6 years ago

LKML post: https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d7...

Earlier discussion: https://news.ycombinator.com/item?id=24170001

cozzyd• 6 years ago

Thanks, maybe it was the expectations set by the tone of The Register article, but the mailing list discussion seemed mostly very reasonable...

londons_explore• 6 years ago

As long as it builds as a module, uses only the standard filesystem apis and doesn't have code changes outside that, code review is far less important IMO...

huhtenberg• 6 years ago

At the risk of stating the obvious, this is an exceptionally short-sighted approach. Committing poorly understood code is not that different from using binary blobs.

lumost• 6 years ago

The linux kernel is successful partly because by and large what's in the kernel works and doesn't generally break on new revisions.

Accepting a new driver which may in fact not work, breaks in ambiguous ways, interacts with other components poorly, or otherwise generates headaches for the kernel could be more trouble than it's worth. Ultimately this driver will eventually need to be modified by others, and ensuing it doesn't get a reputation as a nightmare right out of the gate is also worthwhile.

aronpye2• 6 years ago

So you’d willingly allow tens of thousands of lines of code which you don’t understand or really know what it does into a kernel which is used by literally billions of devices?

cratermoon2• 6 years ago

uses only the standard filesystem apis and doesn't have code changes outside that

That's literally why having to review 27K lines of code is a pain. You're not seriously going to trust, sight unseen, that there's nothing in the code that slips in a backdoor or catastrophic data-loss bug, are you?

segmondy• 6 years ago

I wish you weren't getting downvoted, but what you said is absolutely correct. If it's a module and separate from core, who cares. If it's modifying core kernel or mixed up with kernel space code, then nope.

wtallis11• 6 years ago

Linux isn't a microkernel; a filesystem accepted into the kernel source tree will run as kernel space code whether or not it's compiled as a loadable module. So all 27k lines need to be audited for security purposes and to ensure they're interfacing with the rest of the kernel only in the approved ways, because there aren't a lot of technological barriers to the filesystem misbehaving.

But more important than that is the maintenance burden. NTFS will be around for a long time, but it's also a moving target because Microsoft hasn't replaced it yet. Kernel developers have to keep in mind how this code will look in a few decades, after all the original developers are retired. If it's written in a very different style from other Linux filesystems, will there be anyone left who both knows enough about the workings of the Linux IO stack 20 years hence, and understands Paragon's code conventions?

piscisaureus2• 6 years ago

I understand that reviewing 27k LoC is daunting and probably not very fun.

But unlike most patches that draw a similar response it's not a narrowly useful patch that mostly serves the submitter. Proper NTFS support benefits a large proportion of Linux users (the jab from the article that there are more advanced file systems out there seems out of place; there are no signs that windows is about to switch its default FS to something else).

Additionally this code has been used in production for years now (e.g. my 2015 router runs the closed source version of this driver in order to support NTFS formatted external drives) so most likely a lot of quality issues have already been found and addressed.

So I feel it's a bit unreasonable to respond with so much negativity to this contribution.

AnotherGoodName• 6 years ago

It's also no big deal from either side. Paragon sent in the patch and it's appreciated. There's a few problems to get this in. Reviewers noted the issues and what would need to be done to get this through. The process to get this in is happening.

Split your diff! and Fix your makefile! have to be one of the most benign and common pieces of diff feedback i've seen. I feel that you could make a media story about any submission to the Linux kernel based on there being comments in the review process.

piscisaureus2• 6 years ago

Admittedly I didn't actually read the mailing list discussion. It's entirely possible that The Register made up a big drama where there was none.

geofft• 6 years ago

There were two specific concerns in the initial review that I think were reasonable:

1) The Linux kernel already has an in-kernel read-only NTFS driver. What should be done about it? (There are a number of reasonable options here, including just getting rid of it and replacing it with Paragon's, but that requires at least some buy-in from the maintainers of the existing driver.)

2) The patch didn't actually build, which was a one-line Makefile fix, but raised some concern about how it wax tested/how the patch was generated.

sam42• 6 years ago

In the meantime v2 of the patch has already been submitted, addressing some of the points mentioned in the article: https://lore.kernel.org/linux-fsdevel/904d985365a34f0787a451...

mauvehaus• 6 years ago

Possibly a dumb question, but what are the plusses/minuses of something like this as compared to NTFS-3G?

https://en.wikipedia.org/wiki/NTFS-3G

formerly_proven2• 6 years ago

Mostly better performance / less CPU usage. NTFS-3G is typically CPU-limited even for sequential access, which isn't exactly a great spot for a FS driver to be in.

solarkraft• 6 years ago

NTFS-3G is a userspace (FUSE) driver, which usually have worse performance than kernel drivers.

dTal• 6 years ago

You'll be able to install Linux on NTFS root now!

nix23• 6 years ago

Nice idea, and with Wine we could have all the beautiful Windows AV-Software :-)

mehrdadn3• 6 years ago

I wish Linux on NTFS could share metadata with WSL1. That way you could boot it off the same WSL1 files you could access in Windows.

nippoo• 6 years ago

This is such an odd article. Perhaps Paragon isn't being entirely altruistic with this move but TR are being quite scathing of someone's work submitting a kernel driver with no direct financial reward - and no real praise for, hopefully, fixing one of the biggest out-of-the-box gripes that Windows / Linux desktop dual-boot environments have. It's no small wonder people often complain about the hardships of writing and maintaining open-source software!

shakna• 6 years ago

I don't get where TheRegister is getting the drama. The thread doesn't seem that scathing to me. [0]

It doesn't build, but the person who pointed it out also supplied a diff to make it happen.

It also fails a few tests, but Paragon are more than happy to see if they can make it a bit more compliant.

UBSan finds a few potential bugs, but again, Paragon are more than happy to fix the problems.

There's some style guide suggestions, which Paragon seem to immediately take on board:

The patch will be splitted in v2 file-wise. Wasn't clear initially which way will be more convenient to review.

[0] https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d7...

Delk• 6 years ago

Yeah, The Register can often be witty and irreverent, and I wouldn't complain about that, but that kind of wit only works if there's an actual point behind it. Jumping on the apparently popular bandwagon of squeezing out "drama" from the Linux kernel mailing list isn't adding anything of value.

It also seems a bit ignorant to call the submission "half-baked" just because it needed to be worked on and because someone pointed that out (also) in a slightly irreverent way.

All of those points you bring up about the feedback they got seem like just business as usual for a larger merge of code to a carefully developed FOSS project.

cortesoft• 6 years ago

Yeah, this seems like one of those 'dramas' that incites bystanders more than the actual participants.

aspaceman• 6 years ago

This is why companies don’t open source their code though. Do it and everyone looks at it and says “oh I think you’re stupid”

matthewmacleod• 6 years ago

But that didn’t happen here.

jcrawfordor2• 6 years ago

I think the issue here is the context... Paragon has had a rocky relationship with the Linux community in the past, for example their whiny reaction to exFAT being proposed for mainline a few months ago, so I think in the eyes of The Register there is a certain amount of inherent mistrust in Paragon proposing their NTFS driver for the kernel---shortly after going on the offensive against another formerly-commercial FS going mainline.

That said, I think the tension is more imagined than real, as the LKML doesn't really seem to have responded any more negatively than they do to most other patches.

example: https://arstechnica.com/information-technology/2020/03/the-e...

Fnoord2• 6 years ago

There's no big issue, and there hasn't been one for many years. Ext2/3/4fs read/write support has existed for a long time for Windows, and FUSE/Dokan has a working NTFS driver with r/w support as well (also for a long time). It just doesn't work out of the box (though it does on some distributions).

Its gonna take a while till this driver is mainline in Linux kernel, and till that Linux kernel is included in distributions (especially LTS).

I haven't read The Register article, but in the past it has come to my attention they dramatize their articles, and I don't want to read such media.

Tade0• 6 years ago

I solemnly swear never to complain again about the size of PRs given to me for review.

It's going to take months to throughly assess the quality of this.

Havoc• 6 years ago

Ouch. That looks really useful, but at the same time possibly their first kernel submission perhaps?

Hope I’m wrong but I think they’ll be fighting initial bad impression for a while despite good intention

cactus2093• 6 years ago

It's strange to me that there's no file system with basic features like journaling and support for files larger than a couple of GB, that is supported across all major desktop OSes (MacOS, Windows, Linux, and FreeBSD). All platforms support the same i/o standards like USB or DisplayPort, why did filesystems never make the cut to become a cross-system standard?

Imagine if you could have a backup drive (with reasonable modern data protections) that you could just plug into different systems and save all your files to. Isn't it odd that such a simple thing isn't possible? I guess network attached storage has gotten pretty accessible at this point so there's no need for it?

quarantine• 6 years ago

There's a ZFS driver for Linux, macOS, and Windows.

wtallis11• 6 years ago

In all three cases you list, it's a third-party module providing support, rather than it being a standard feature of the OS that can be expected to be generally available on more than 1% of the install base.

hoistbypetard• 6 years ago

ZFS development moves so fast that it is common for my (FreeBSD-based) FreeNAS box to warn me when I upgrade my OS that certain actions will make it incompatible with the prior version of FreeNAS.

That is fine and appropriate for a drive that will be connected to the system for the foreseeable future.

That kind of compatibility concern makes me squeamish about using ZFS for a drive that I want to share between different systems. If it's easy to make it incompatible between two releases for the same system, that smells like a waiting nightmare trying to keep it compatible between Linux, FreeBSD and Windows.

Wowfunhappy4• 6 years ago

The ZFS driver is still early in development and quite unstable! I’ve used it in read-only mode just so I could have some access to my ZFS pool while booted into Windows, and although it kind of worked in that use case it was would still do weird things like randomly refuse to open certain files.

Fnoord2• 6 years ago

There's a Btrfs driver for Windows [1]

[1] https://github.com/maharmstone/btrfs

jcrawfordor2• 6 years ago

I think the basic problem is that FAT is generally "good enough," and in the increasingly common case where it isn't exFAT is close to universal and addresses the only problem that consumers frequently run into (file size limit).

While FAT/exFAT leave the possibility of a variety of different types of filesystem inconsistency, these seem to be fairly rare in actual practice, probably in good part due to Windows disabling writecaching on devices it thinks are portable. This kind of special handling of external devices is sort of distasteful, and leads to some real downsides on Windows (e.g. LDM handling USB devices weird), but using a newer file system doesn't really eliminate that problem - NTFS and Ext* external devices require special handling on mounting to avoid the problems that come from file permissions traveling from machine to machine, for example.

Wowfunhappy4• 6 years ago

I don’t know if it’s just because I’m largely on Mac and Apple’s drivers suck, but I have run into lots of data corruption issues with exFAT on large drives (1TB+). More than enough for me to stop using it.

(Now I use NTFS and Tuxera’s commercial Mac driver, because I don’t know how else to have a cross-platform filesystem without a stupidly-low file-size limit.)

wheybags3• 6 years ago

in good part due to Windows disabling writecaching on devices it thinks are portable. This kind of special handling of external devices is sort of distasteful

What's distasteful is that on my linux machine with a lot of ram, when I copy a multiple gigabyte file to a USB key it "completes" the copy almost immediately, when actually all it has done is copy the file to a ram buffer. Then when I try to disconnect the drive, it will hang for ages while it actually finishes the write. IMO windows does it better here (although I never realised what exactly they did, nice to know.

rini17• 6 years ago

Yes there are still dreams about bringing your home directory on a stick anywhere with you and just plugging it into nearest public toilet when you need it.

But it hasn't and won't work for obvious reasons.

qalmakka3• 6 years ago

Ironically, a fully encrypted Linux installation with Btrfs or ZFS on a removable drive is quite easy to make and it works really well. I've one I made on an old SSD I had lying around and a 2.5" USB-C caddy and it's wonderful, you can have your work environment everywhere you want and even plug it into a running machine and boot it up using Hyper-V or KVM.

0xcde4c3db2• 6 years ago

UDF looks a lot like that file system on paper, but my understanding is that it practically falls apart because there are too many bugs and too much variation in which features are really supported among the various implementations. Everyone agrees on the DVD-ROM subset, but beyond that it seems like a crapshoot.

franga2000• 6 years ago

Not standardising means being able to distinguish yourself easier, it's just that for anything that integrates with third-party stuff, standardisation is way cheaper. Apple doesn't make monitors or flash drives, so making their own specs for those wouldn't be beneficial to them and would increase prices of compatible products. But a filesystem is something they do make and being able to do whatever they want with it is quite beneficial, with no downsides as there are no third parties (that they care about) integrating with it that would have to put in extra work to support it (besides their direct competitors, which is a nice bonus).

sedatk4• 6 years ago

exFAT is such a file system. It doesn't have journaling but why do you need journaling on backup media anyway?

toyg6• 6 years ago

Because shit can happen even when you're backing up...?

mschuster912• 6 years ago

why did filesystems never make the cut to become a cross-system standard?

Many reasons, the most important being patents and insistence by vendors to keep stuff proprietary (exfat, ntfs, HFS, ZFS).

Also, there are fundamental differences on the OS level:

- how users are handled: Unices generally use numerical UID/GID while Windows uses GUIDs

- Windows has/had a 255-char maximum length of the total path of a file

- Unices have the octal mode set for permissions, old Windows had for bits (write protected, archived, system, hidden) and that's it

- Windows, Linux and OS X have fundamentally different capabilities for ACLs - a cross platform filesystem needs to handle all of them and that in a sane way

- don't get me started on the mess of advanced fs features (sparse files, transparent compression, immutability of files, transparent encryption, checksums, snapshots, journals)

- Exotic stuff like OS X and NTFS additional metadata streams that doesn't even have representation ín Linux or most/all BSDs

And finally, embedded devices and bootloaders. Give me a can of beer and a couple weeks and I'll probably be able to hack together a FAT implementation from scratch. Everything else? No f...in' way. Stuff like journals is too advanced to handle in small embedded devices. The list goes on and on.

wesnerm2• 6 years ago

Windows has/had a 255-char maximum length of the total path of a file

The actual path of file in Windows can be practically unlimited, but either requires using special network notation that can exceed 256 characters or relative addresses. Recent versions of Windows includes a setting that removes the limitation in the APIs because of development issues like node nested packages.

TheOtherHobbes• 6 years ago

Filesystems have never been standardised. In mainframe/mini days manufacturers supplied a selection of OS options for the same hardware, and there was no expectation that the various filesystems would be compatible between different OSs.

Which is why we have abstraction layers like Samba (etc) on top of networked drives. They're descendants of vintage cross-OS utilities like PIP which provide a minimal interface that supports folder trees and basic file operations.

But a lot of OS-specific options remain OS-specific, and there's literally no way to design a globally compatible file system that implements them all.

This isn't to say a common standard is impossible, but defining its features would be a huge battle. And including next-gen options - from more effective security and permissions, to content database support, to some form of literally global file ID system, to smart versioning - would be even more of a challenge.

JdeBP• 6 years ago

Windows uses SIDs, not GUIDs.

jchook• 6 years ago

Almost as if the corporations have a conflict of interest with their consumers.

opan• 6 years ago

ISO 13346[0] is supported everywhere and can handle files larger than 4GB. It's used on DVDs, but it can also be used on a flash drive[1].

[0] https://en.wikipedia.org/wiki/Universal_Disk_Format [1] https://github.com/JElchison/format-udf

qalmakka3• 6 years ago

Using a non-FAT filesystem for portable storage opens up lots of issues regarding broken permissions. Try to create a file on an ext4-formatted USB flash drive using your current user; rest assured that, unless your remembered to set its permissions to 777, on another computer you'll have to chmod it because it still belongs to the possibly dangling creator's UID and GIDs. If you don't have root access, and unless coincidentally your user has the same UID as your other machine, you're screwed and you have to go back grumpingly to a system where you have administrative privileges.

Same thing applies to NTFS, but I've seen that more often than not Windows creates files on removable drives with extremely open permissions, and in my experience NTFS-3G just straight ignores NTFS ACLs on the drives it mounts, so more often than not it JustWorks™ in common use cases.

I think a journaled extFAT-like filesystem would be perfect for this task, but given how hard it was for exFAT to even start to displace FAT32, even if it actually existed I wouldn't expect it to succeed any time soon.

beervirus• 6 years ago

27k is 27 kB.

This is 27 kLOC.

prirun• 6 years ago

It's just a single data point, but I tried Paragon's ext4 driver (the paid version) for Mac many years ago. It seemed to work, but when the drive was connected back to Linux, there were all kinds of fsck errors. Immediately deleted it.

apfsx• 6 years ago

This has also been my exact experience. I used Paragon's NTFS driver (paid) for Mac for my external SSD. After using, when plugging into Windows it would always find "errors" and recommend to Scan and Fix them.

Wowfunhappy4• 6 years ago

Fwiw, I had the same problem with Paragon but have had a lot more success with Tuxera’s driver, if you’re still looking for a solution.

adamretter• 6 years ago

I hope the it's better than their ext2 drivers for macOS. I have had nothing but problems and data loss and their support is the worst.

jug• 6 years ago

Same on Windows regarding data loss. Terrible and I’ll never use their ext2 drivers again.

aaron6953• 6 years ago

"It looks as though that with NTFS being surpassed by other more advanced file-systems,

Is this remotly true?

Will my grandmother not be using NTFS in 10 years?

wtallis11• 6 years ago

Microsoft has been trying to come up with a replacement for NTFS for a very long time. They've had mixed success with trying to extend NTFS with more advanced features like the now-deprecated TxF. There's little doubt that even its creators see NTFS as something of a dead-end. Whether your grandmother is still using it in 10 years depends primarily on whether Microsoft can get its act together to pick and ship a replacement.

aaron6953• 6 years ago

Whether your grandmother is still using it in 10 years depends primarily on whether Microsoft can get its act together to pick and ship a replacement.

So yes she will I guess.

Then it's vital Linux gets NTFS working well.

My partner is not going to use Linux things if every time they try and transfer the 8k 3D holographic photos of our CRISPR'ed dog learning to spell to my grandmother it doesn't work on her Holovision.

True story, last month I just lost about 1 in 10 of my media files on my Linux Share to NTFS issues. So now I run the box on Windows.

PhoenixRobo• 6 years ago

Does it need to be included in the Linux Kernel? I understand that NTFS is 27 years old and mostly to support Microsoft file systems. Can't the driver be an external download?

EE84M3i• 6 years ago

In-tree drivers are the standard for Linux kernel modules.

bArray3• 6 years ago

27k lines isn't that crazy. I've merged larger patches, it just takes a while. This is a very negative view of an open source contribution.

wtallis11• 6 years ago

I've merged larger patches,

In what kind of context? The Linux kernel?

Filesystem code is pretty tricky to begin with, and prone to very subtle bugs with very not-subtle consequences. And this isn't greenfield development of a new filesystem, but an implementation that needs to remain highly compatible with Microsoft's version. This FS driver has to be maintained to track changes to two operating systems. So this 27kloc can reasonably be expected to encompass a lot more complexity than your average 27kloc, and it requires a lot more review effort than something like 27kloc of GPU driver register definitions.

bArray3• 6 years ago

In what kind of context? The Linux kernel?

Not the Linux kernel, but a large embedded system.

Filesystem code is pretty tricky to begin with, and prone
to very subtle bugs with very not-subtle consequences.

This code has been running in the wild for quite a while now, it has had a trial by fire. And there's no way around testing, subtle ext4 bugs still crop up despite the maturity of the filesystem.

And this isn't greenfield development of a new filesystem,
but an implementation that needs to remain highly
compatible with Microsoft's version.

No amount of code review will stop Microsoft from adapting their version. Also, I doubt Microsoft themselves will change too much about the filesystem given the compatibility they themselves have to maintain with cold storage NTFS drives.

This FS driver has to be maintained to track changes to
two operating systems.

You make it sound as if Microsoft have a hand in any of this. Also, have you seen the state of the current NTFS driver? It's a bit flakey (no disrespect to the maintainers).

userbinator• 6 years ago

I wonder if the reason for the huge line count is overly verbose code, or if it's just the inherent complexity of NTFS. For contrast, I wrote a FAT32 filesystem driver (read/write) for an embedded system a long time ago, and it was less than 1K lines --- of Asm.

The_Colonel• 6 years ago

NTFS is way more complicated (and feature rich) filesystem than (rather barebones) FAT32.

r41nbowdash• 6 years ago

200loc/h, it's 4-5 weeks of work for a single person

Paragon submits 27k-line NTFS driver to Linux kernel

Related Stories