When in Rome do as the Romans do. Maybe we should only run windows virtualized :)

It'd be so fracking sweet to see filesystems follow this pattern. If we could re-use the file system logic, but apply it to windows or fuse or Linux or wasm linearly-addressed-storage, that would allow such intensely cool forms of portability/reuse & bending/hacking.

But isn't this just good old inversion of control, modularity with maybe some inspiration from Functional Programming. Or even more generally, good Software architecture and engineering?

Anyway, I'm very happy to see this, the more code is architected this way, the better for all our industry.

Not to join in too much on the "but we already had this!" bandwagon ... but actually to join in the bandwagon - we had these sorts of patterns in C 20 years ago. I worked with a TLS implementation like this sometime around 2005.

Either you work with buffer-in/buffer-out types of scenario, or you register callbacks to do the real IO.

It's a great pattern and means that you can do stuff like change transport mechanism, or put in proxying, or whatever you want really, without having to change the library.

With embedded C stuff it was also relatively common to handle memory allocation this way - buy in a library that does whatever proprietrary thing you need from a vendor, then register your custom allocator with it so when it needed heap memory, you could provide that in line with whatever platform restrictions you had going.

Wonder how well it scales to larger applications. Ie is there a codesize where io-less becomes too difficult? Perhaps performance concerns? Hmm

Also, quite the opposite, it's *easier* to design a library this way because it's strictly less code the library needs to contain. Specifically in Rust it also has the advantage that the library becomes agnostic to sync vs async I/O since that's handled by the library user. Correspondingly, it is slightly harder for the library user to use such a library, but it's usually just a matter of writing a tiny generic wrapper around the network socket type to connect it to the library functions.

That said, a lot of what’s actually hard about IO is the error/fault handling, imposing timeouts and backoffs and all that jazz. At a certain point I’d wonder if extracting this out to a separate interface might obscure the execution flow in some of these scenarios.

Application-level timeout/backoff handling is always scary to me, because I don't know how to make robust tests for it. I wonder if you couldn't use the same I/O-less approach, and split the logic out into pure functions that take the time passed/error state/... as value arguments, instead of measuring the physical time using OS APIs. It's probably not something for reusable libraries, but it could still be a nice benefit to be able to unit test in detail.

Then you can test the decision function trivially, the re-try function by mocking the action and decision, and the action function itself without back off interfering.

That’s what you suggested, just saying that I did that in a Python API client with the backoff library and the result is pretty neat.

This could be the first FS that just-works across nix, Mac and windows since fat.

Anyone contemplating use and rattled about data corruption etc on btrfs partitions and drives, focus on mount options in README

1. use `Ignore` for (arch)linux system partition 2. use `Readonly` for everything else

That being said, I never faced cpu spikes/corruption using the driver on 20TB external HDD with complete btrfs zstd:2 compression mount

Winbtrfs only says the raid5 mode is one of the features, but doesn't really address how well it works. The questions in a related issue (https://github.com/maharmstone/btrfs/issues/293) have been closed without real answers. I wouldn't risk raid 5/6 on it without getting good answers about the status / testing from the developers first.

I’m not taking anything away from the effort that has gone into producing this. Just being realistic about the amount of effort that is required to create a production ready file system driver.

I recall reading somewhere recently, that the Linux btrfs developer intends to fix these edge cases through a on-disk layout change (IIRC, adding one more btree to the filesystem). So unless this driver already has that on-disk layout change, it's unlikely that these edge cases have been addressed.

Anyone using this long term or in production who can comment on how it's been working?

I see TRIM is supported. Is RETRIM also (or whatever is needed during drive optimization to release areas that didn't get TRIMmed the first time due to a full command queue).

Could this serve as an effective NTFS replacement with data parity for those who don't like ReFS?

How mature is it compared to ZFS on Windows?

I don’t use it often, but when I do I don’t even notice it. It’s as if Windows could just natively read btrfs all along. This was without any “advanced” usage beyond simply accessing, modifying, or deleting files.

While that statement might well be correct that the quote is in fact an anecdote, the following is also an anecdote: ‘From what I’ve heard, BTRFS has a crazy long list of defects where it’ll lock up or corrupt data if you so much as look at it wrong.’

For me I decided to not touch it anymore after that experience. I'm sure there is a name for that bias but I don't care. Got burned badly. Lots of people had probably similar experiences and that's were that coming from. Reading the mailing list archives at that time might also be useful to convince yourself that it was more than anecdote.

Provide actual data that’s recent. Linux 4.x was what, 10 years ago? Cars are substantially safer now than they were 10/20/50 years ago, so whose to say your experience with a file system would be different?

You probably just don't, as the alternatives are good and plenty.

Which cannot be said about file systems on Linux which support metadata+data checksum and repair though. As far as I'm aware the only file systems which could realistically be used are btrfs and zfs (bcachefs looks promising but not there yet). Zfs is not even a part of the kernel and you have to compile it yourself and hope it does actually compile against your kernel due to API changes.

Conversely, witnessing defects does not itself prove defects exist if the test cases were not scientific, it increases the confidence that defects exist but there exists some probability that an unrelated defect (bad ram, kernel error, hardware failure, solar flares) could have caused the issue.

But there’s also a lot of evidence to suggest Brtfs has had a lot of defects resolved in recent years, so it’s also important to note that as time moves forward, the amount of existing and likely rate of introducing new defects is likely to decrease.

I should add ive had minimal skin in this game until yesterday. I chose brtfs for two systems for snapshot support, but that’s in addition to regular backups on another host, because it’s silly to trust any single compute node regardless of file system.

No. It is referring to the Flying Spaghetti Monster, but is an analogy for anything including defects. This is discussion about epistemology not filesystems.

The list cannot be crazy long if Synology uses it for their NASes.

Personally, BTRFS is the only filesystem that has ever caused me any data loss or downtime. I was using a single disk, so it should have been the perfect path. At some point the filesystem got into a state where the system would hang when mounting it read/write. I was able to boot off of a USB stick and recover my files, but I was unable to get the filesystem back into a state where it could be mounted read/write.

At work, we used to run BTRFS on our VMs as that was the default. Without fail, every VM would eventually get into a state where a regular maintenance process would completely hang the system and prevent it from doing whatever task it was supposed to be doing. Systems that wrote more to their BTRFS filesystems experienced this sooner than ones that didn't write very much, but eventually every VM succumbed to this. Eventually the server team had to rebuild every VM using ext4.

I know that anecdotes aren't data, but my experience with BTRFS will keep me from using it for anything even remotely important.

So no, I don’t think we got what we paid for.

Facebook could easily work around failures, they've surely got every part of their infrastructure easily replaceable, and probably automated at some level. I'm sure they wouldn't tolerate excessive filesystem failures, but they definitely have the ability to deal with some level of it.

But Synology deploys thousands of devices to a wide variety of consumers in a wide variety of environments. What's their secret sauce to make BTRFS reliable that my work's commercial Linux distribution doesn't have? Surely there's more to it than just running it on top of md.

Maybe in the years since I was burned by it things have greatly improved. Once bitten, twice shy though - I don't want to lose my data, so I'm going to stick to things that haven't caused me data loss.

And besides, if you are doing RAID you are probably concerned with the system's uptime which probably means you will have implemented such measures anyway.

Note that, yes, I'm aware most home users either aren't aware (nobody RTFM) or are too lazy/cheap to buy a UPS from Office Depot. So perhaps btrfs is warning people to save them from themselves.

And lost writes are a problem that all filesystems have. I recommend reading the paper "Parity Lost and Parity Regained" by Krioukov at USENIX 08...

One example: If you (accidentally or on purpose) attach a ReFS disk or LUN to a newer Windows version, it will be silently upgraded to a new ReFS version without any feedback (or chance to prevent it) for the user. No way of attaching the disk on an older Windows version afterwards. But that is not the real problem. The real problem is that the upgrade runs as a separate (user-space) process. If this process crashes or your PC crashes or reboots while it runs, your data is gone. There is no feedback how long it still has to run (we've seen multiple days on large volumes)

So yeah, maybe avoid ReFS for a few more years...

That is rather useful in backup systems.

XFS also supports reflinks amongst other things and is way older than ReFS and hence considered out of beta (which ReFS isn't, by me)

I don't trust data to RefS yet - its a fun project that will no doubt prove itself one day. For now, Windows boxes run NTFS and Linux runs ext4 or XFS.

If you're going to make 11 copies, they have to go to different physical locations, different devices at least, geographically different places to be sure, or it's pointless.

In this instance, block de-duping on a single device makes sense .. expecting mutiple copies on the same device (with or without duplicat block reuse) to offer any additional safety does not.

Also if you turn on data checksums, my understanding is it will delete any file that gets a corrupted sector. And you can only override this behavior on a per-file basis. Unless this changed very recently?

I tried ReFS when it first came out and it was terribly slow (with data parity on), and Storage Spaces was obscure to set up and manage. Has the landscape improved?

I had spoken with some of the teams involved and they were rather cagey about the root cause, but at least one person mentioned that there were some fixes in the pipeline for Windows Server 2022 NVMe support. I guess this must have been it!

I would love to see that the new version works with fewer problems.

Hardware RAID is worth the money when uptime and performance are important. I've seen good RAID cards keep a server running where native direct SATA would have brought the server down.

The advantages were always theoretical and the disadvantages were always real. It caused way more problems than it solved or prevented, and the problems are worse because you are essentially powerless to address them.

With software raid you have the control to address problems even when you fall off the happy path, and infinite flexibility wrt hardware and emergency recovery.

In macro, hardware raid is less reliable, not more. Performance is no better than a draw, not better.

With software RAID, you can just plug the disks into other servers without those kinds of problems.

In practice it works out pretty decently in my experience using it with windows 10 daily for a while, with a few caveats:

1. You need a stable usb connection

2. You need a usb drive enclosure with a controller chip that is stable/doesn’t overheat

3. Your drive should be powerless resistant. Unfortunately there’s no resource I know of that evaluates power loss handing. Some drives will have a bad time having power suddenly cut. I’ve had good experience with Intel enterprise sata SSD’s and NVMe drives in a Dockcase with capacitor. If your drive stops showing up, a power cycle might help: https://dfarq.homeip.net/fix-dead-ssd/

4. Have automatic backups setup.

Very useful for performance testing and hardware firmware updates that are windows only.

When switching between computers, I’ll often have to boot, windows gets confused and then reboot. After that it works.

However, I have no experience trying to make use of WinBTRFS or the separate bootloader project, which is apparently currently broken since a few months ago.

Ventoy booting a windows VHD file might also be a decent option

I've got a testing install of Windows on my main hard drive that boots from VHDX for these reasons

When is the year of the btrfs file system coming?

The issue is that btrfs still does not run perfectly rock solid on raid other than 0 and 1.

Plus it's compression and performance is still far off what alternatives can provide (but this is also getting better).