Implementing eBPF for Windows

Posted Jun 14, 2021 13:37 UTC (Mon) by nix (subscriber, #2304)
In reply to: Implementing eBPF for Windows by Cyberax
Parent article: Implementing eBPF for Windows

> As a result filesystem performance on NT is a joke,

Filesystem performance on NT is not impaired by backwards compatibility -- or, rather, backwards compatibility isn't the main problem with it. NTFS was widely known as a dog even in the 90s before the backwards-compatibility burden emerged, and it has not got much better: indeed, MS spent a *lot* trying to replace it, overdesigned the replacement, WinFS, which failed (a shame, it was fascinating) and are still stuck with NTFS as a result.

Backwards compatibility might be a problem as well, but this isn't an example of it :)

Implementing eBPF for Windows

Posted Jun 14, 2021 21:18 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I have written a couple of filesystems for Windows. Including a simple in-memory one that doesn't even touch the persistent storage. It was slower than ext3 on Linux.

The issue is that for any request except the basic read/write ops Windows needs to create an IRP (I/O Request Packet) that is routed and filtered through multiple layers. So for example, you can attach filters that would change the file names. Or transparently encrypt the data and metadata as it's being written. This also makes stuff like ransomware pretty easy to do.

The downside is that this very abstract system is pretty slow.

Implementing eBPF for Windows

Posted Jun 15, 2021 19:07 UTC (Tue) by nix (subscriber, #2304) [Link]

We had that on Unix once: STREAMS. Powerful, abstract... and slow. It's a bit of a shame it didn't stick around, but on free-software operating systems you can always just copy the filesystem and hack the source of the copy directly, so this degree of abstraction is fairly pointless.