News for hackers. Stuff that matters.
Re:NTFS read-write GPL kernel driver by lizknope on Saturday August 15, 2020 @03:56PM (#24171853)
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
Re:NTFS read-write GPL kernel driver by speedgoose on Saturday August 15, 2020 @04:11PM (#24171962)
NTFS is super slow on windows too. You get better performances with ext4 on WSL2 (Windows Subsystem for Linux).
Re:NTFS read-write GPL kernel driver by mehrdadn on Saturday August 15, 2020 @04:29PM (#24172111)
This is not an NTFS issue. You can verify it by trying a different file system.
Re:NTFS read-write GPL kernel driver by throwaway8941 on Sunday August 16, 2020 @01:23AM (#24175410)
Here's more or less official description of this issue.

https://github.com/Microsoft/WSL/issues/873#issuecomment-425...

Re:NTFS read-write GPL kernel driver by verst on Sunday August 16, 2020 @02:28AM (#24175726)
WSL2 simulates a virtual ext4 file system. If you want to access ext4 natively from WSL2, wait for the next Windows Insiders release!
Re:NTFS read-write GPL kernel driver by risho on Saturday August 15, 2020 @04:13PM (#24171982)
how is this possible? isn't wsl 2 literally a virtual machine image on top of your ntfs drive?
Re:NTFS read-write GPL kernel driver by neurostimulant on Saturday August 15, 2020 @05:24PM (#24172534)
I think it bypassed windows filesystem filters (antivirus, etc) and thus faster because there is nothing taxing your read/write operations.
Re:NTFS read-write GPL kernel driver by tfigment on Sunday August 16, 2020 @01:27AM (#24175430)
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.
Re:NTFS read-write GPL kernel driver by verst on Sunday August 16, 2020 @02:32AM (#24175741)
The WSL2 kernel at this time cannot access ext4 partitions natively. Only partitions available in Windows can be mounted in WSL2. So that means installing ext4 drivers...

WSL2 itself uses a virtual file system.

Re:NTFS read-write GPL kernel driver by speedgoose on Saturday August 15, 2020 @04:37PM (#24172168)
Yes but it's only one big file, the ext4 partition.
Re:NTFS read-write GPL kernel driver by Tuna-Fish on Saturday August 15, 2020 @05:20PM (#24172505)
And to extend, Windows/NTFS is not particularly slow at accessing a large file (actually, until recently they have been ahead for async read/write into big files), the area where they really suck is anything that has anything to do with metadata.
Re:NTFS read-write GPL kernel driver by ufmace on Saturday August 15, 2020 @06:26PM (#24172967)
I had heard the issue was with how Windows/NTFS let a bunch of extensions place hooks into reading and writing files. Antivirus apps would sometimes put a bunch of heavy-ish hooks in that would be terrible for performance with lots of tiny files, which many Unix-y workflows expect to be able to do quickly.
Re:NTFS read-write GPL kernel driver by opencl on Saturday August 15, 2020 @07:00PM (#24173166)
The "sometimes" includes the one Microsoft ships by default with Windows. It is ridiculous how much faster random file access becomes when disabling Defender's real time protection feature.
Re:NTFS read-write GPL kernel driver by ziml77 on Sunday August 16, 2020 @12:20AM (#24175064)
It's one of the most impactful AVs when it comes to file r/w speed, especially on lots of small files. I have no idea why I still see people calling it lighter and faster than other AV options. It's not even like the performance loss is getting better protection. Products like Bitdefender and Kaspersky have better detection rates and don't murder performance. (Personally I just turn it off and don't install a replacement)
Re:NTFS read-write GPL kernel driver by giancarlostoro on Sunday August 16, 2020 @12:40AM (#24175178)
This is probably why JetBrains IDEs suggest to add your projects to antivirus exceptions for you. I rarely ever have performance issues while developing anymore after I let JetBrains do its thing.
Re:NTFS read-write GPL kernel driver by formerly_proven on Saturday August 15, 2020 @05:38PM (#24172651)
I've been told this has to do with NTFS using a complicated metadata scheme and also all permissions in NTFS being backed by a complex ACL-security-descriptor scheme. Is that an accurate representation?
Re:NTFS read-write GPL kernel driver by Tuna-Fish on Saturday August 15, 2020 @06:02PM (#24172807)
I don't believe it is. Windows metadata performance is not just bad, it's so bad it beggars belief. I don't believe the root cause is any specific technical decision, but rather that no-one cares about it. It has always been so bad that no-one can count on it, so no-one depends on it, so it's something that can safely be ignored.

On Linux, and other unices, there have always been important workloads where it really matters, so that itch got scratched.

Re:NTFS read-write GPL kernel driver by bleepblorp on Saturday August 15, 2020 @11:32PM (#24174768)
Windows filesystem metadata performance is also highly dependent on how applications access metadata. It's a lot slower than it needs to be, especially for software ported from Linux (or POSIX-like environments in general), because metadata access has to be done in a Windows way to be performant.

Windows metadata performance is horrendously bad for code that needs to get metadata for a large number files in the same folder the way it would be done on Linux: by calling the Windows equivalent of `stat` (`GetFileAttributesEx`) for every file.

Metadata performance is much better if the code uses `FindFirstFileEx`, which IIRC has no direct Linux equivalent, to grab metadata en masse for all files in a folder and then filtering the results down the files that the code needs to know about.

Unfortunately, most code ported to Windows from Linux uses `GetFileAttributesEx`, under the assumption that it's as fast as `stat` is on Linux, but results in a poor user experience. Worse, many modern cross-platform languages (including Python) don't expose `FindFirstFileEx` without platform-specific add-ons, which means that devs have no easy way to do Windows metadata access right even if they know there's one specific way to do it.

Re:NTFS read-write GPL kernel driver by formerly_proven on Sunday August 16, 2020 @05:47AM (#24176507)
os.scandir in Python was designed to encapsulate "listdir replacement APIs" and uses FindFirstFile/FindNextFile on Windows, and also allows most stuff to be done without an extra per-file stat() syscall on Linux. On top of that, when accessing many/all files in a folder in Linux, this gives you the inode, and if you sort your accesses by inode, throughput can rise to the ninth power on hard drives.

On the other hand, if you look at e.g. Windows Explorer. Explorer will take somewhere from a few seconds to ~tens of seconds to list the contents of a SSD-backed directory with a couple thousand files. The same operation on Linux is practically instant. Copying a bunch of small files on Windows takes forever, maybe doing around a few hundred files per second. Meanwhile Linux will happily copy thousands of files per second, all on the same hardware.

Explorer might be using incorrect ways to do I/O, but if that is the case, then that would mean that the proprietary, only-ever-developed-for-Windows-by-Microsoft tool that is also the main way users do I/O doesn't do I/O properly. What would that say about Windows?

Re:NTFS read-write GPL kernel driver by wongarsu on Sunday August 16, 2020 @09:46AM (#24177719)
If I remember correctly Windows Explorer still doesn't support long paths (paths with a total length over 255 characters). It only recently gained the ability to create files starting with a dot. It has no support whatsoever for alternate data streams, let alone more obscure NTFS features.

I wouldn't be surprised if it used the wrong API (in fact the lack of long path support is an example of using an outdated API). The only reason Windows Explorer appears reasonable is because people generally consider creating files you can't access with Windows Explorer a bug or misfeature.

Re:NTFS read-write GPL kernel driver by p_l on Sunday August 16, 2020 @04:50PM (#24181193)
Explorer not only appears to be heavy on the "Windows Classic" APIs, somehow to this day, but it also does a bunch of stuff ower file compared to let's say ls.

In fact, if you use Total Commander, in the settings you will find option regarding things like "getting correct icons for files", with the option for "display icons for all files" explicitly marked as "SLOW".

Explorer always gets the icons, and possibly other metadata.

Re:NTFS read-write GPL kernel driver by bleepblorp on Sunday August 16, 2020 @04:08PM (#24180798)
Os.scandir looks like a very good improvement to Python. I haven't coded anything to Python 3.5 or newer, however, so I have no experience with it.

The last time I needed something along these lines the only option were os.listdir or using FindFirstFile through win32py. Os.listdir was an order of magnitude slower for my use case.

Re:NTFS read-write GPL kernel driver by loeg on Saturday August 15, 2020 @07:46PM (#24173456)
I don't agree that it's because no one cares about Windows metadata performance; both userspace/3rd-party developers and the kernel engineers care. Rather, they are loath to break any published API, and their metadata performance suffers from the limitations imposed by those historical design decisions (filter drivers, etc).
Re:NTFS read-write GPL kernel driver by dboreham on Saturday August 15, 2020 @09:35PM (#24174070)
They didn't anticipate a workload where files would be opened and closed very frequently. E.g. running npm. Applications accessing large numbers of small records were expected to do so via a big file containing all the records a la SQLServer.
Re:NTFS read-write GPL kernel driver by formerly_proven on Sunday August 16, 2020 @05:48AM (#24176515)
Yet MSI and Windows Update love their gazillion of tiny files, probably one of the reasons why WU is so slow (aside from the "let's solve P=?NP" thing that Windows 7 does). Game devs have got it right for decades though, practically every game ships their own little take on random-access ZIP archives (they often used profiling to arrange the files inside the archives in the order the game would load them as well, though that is probably less important these days), because that's so much faster than using the host file system.
Re:NTFS read-write GPL kernel driver by rurban on Saturday August 15, 2020 @11:41PM (#24174830)
Inherited ACL's are not cached, so it's super slow. When you turn that off and set every ACL manually, it's fast.
Re:NTFS read-write GPL kernel driver by tinus_hn on Sunday August 16, 2020 @01:38AM (#24175490)
Inherited ACLs are applied at file creation time, they can even get out of sync.
Re:NTFS read-write GPL kernel driver by microcolonel on Saturday August 15, 2020 @07:55PM (#24173511)
I've seen numbers in some workloads where ntfs-3g is 40% faster than NTFS on Windows, despite crossing between userspace and the kernel three times for every filesystem call (recent work in the kernel will potentially cut this down to two context switches each way for FUSE).
Re:NTFS read-write GPL kernel driver by Macha on Saturday August 15, 2020 @09:13PM (#24173941)
Same story here, I do not remember a time when I couldn't read/write NTFS from Linux since I started using it in with Ubuntu 8.04