Is anyone using it around here?
Took roughly one week for the whole raid to stop mounting because of the journal (8hdd, 2 ssd write cache, 2 nvme read cache).
The author responded on Reddit within a day, I tried his fix, (which meant compiling the Linux kernel and booting from that), but his fix didn't resolve the issue. He sadly didn't respond after that, so I wiped and switched back to a plain mdadmin raid after a few days of waiting.
I had everything important backed up, obviously (though I did lose some unimportant data), but it did remind me that bleeding edge is indeed ... Unstable
The setup process and features are fantastic however, simply being able to add a disk and flag it as read/write cache feels great. I'm certain I'll give it another try in a few years, after it had some time in the oven.
And even if you have the time and patience to be one of these early adopters, debugging any issues encountered might also be difficult, as ideally you want to give the devs full access to your filesystem for debugging and attempted fixes, which is obviously not always feasible.
So anything beyond the most trivial setups and usage patterns gets a miniscule amount of testing.
In an ideal world, you'd nail your FS design first try, make no mistakes during implementation and call it a day. I'd like to live in an ideal world.
Crypto implementations and FS implementations strike me as the ideal audience for actually investing the mental energy in the healthy ecosystem we have of modeling and correctness verification systems
Now, I readily admit that I could be talking out of my ass, given that I've not tried to use those verification systems in anger, as I am not in the crypto (or FS) authoring space but AWS uses formal verification for their ... fork? ... of BoringSSL et al https://github.com/awslabs/aws-lc-verification#aws-libcrypto...
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
Kent wants to fix a bug with large PR
Linux doesn't want to merge and review PR that touches so many non-bcachefs things.
They're both right in a way. Kent wants bcachefs to be stable/work good, Linus wants Linux to be stable.
Kent from bcachefs was just late in the cycle, somewhere in rc5. That was indeed too late for such a huge push of new code touching so many things.
There is some tension but there is no drama and implying so is annoying.
Bcachefs is going places, I think I’d already choose it over btrfs atm.
Linus "regretted" it in the sense "it was a bit too early because bcachefs is moving at such a fast speed", and not in the sense "we got a second btrfs that eats your data for lunch".
Please provide context and/or short human-friendly explanation, because I'm pretty sure most readers won't go further than your comment and will remember it as "Linus regrets merging bcachefs", helping spread FUD for years down the line.
But...
Strongly disagree.
I think that is a very unfair reading of what I wrote. I feel that you might have a bias which shows but that would be the same class of ad hominem as you have just displayed. That is why I choose to react even though it might be wise to let slepping dogs lie. We should minimize polarization but not to a degree where we cannot have civilized disagreement. You are then doing exactly what you preach not to do. Is that then FUD with FUD on top? Two wrongs make a right?
I was reacting on the implicit approval in mentioning that it had been upstreamed in the kernel. The reason for the first link. Regrets where clearly expressed.
Another HN trope is rehashing the same discussions over and over again. That was the reason for the second link. I would like to avoid yet another discussion on a topic which was put into light less than 14 days ago. Putting that more bluntly would have been impolite and polarizing. Yet here I am.
The sad part is that my point got through to you loud and clear. Sad because rather than simply dismissing as polarizing that would have been a great opener for a discussion. Especially in the context of ZFS and durability.
You wrote:
> Linus "regretted" it in the sense "it was a bit too early because bcachefs is moving at such a fast speed", and not in the sense "we got a second btrfs that eats your data for lunch".
If you allow me a little lighthearted response. The first thing which comes to mind was the "They're the same picture" meme[1] from The Office. Some like to move quickly and break things. That is a reasonable point of view. But context matters. For long term data storage I am much more conservative. So while you might disagree; to me it is the exact same picture.
Hence I very much object to what I feel is an ad hominem attack because your own worldview was not reflected suitably in my response. It is fair critique that you feel it is FUD. I do however find it warranted for a filesystem which is marked experimental. It might be the bees knees but in my mind it is not ready for mainstream use. Yet.
That is an important perspective for the OP to have. If the OP just want to play around all is good. If the OP does not mind moving quickly and break things, fine. But for production use? Not there yet. Not in my world.
Telling people to ignore my comment because you know people cannot be bothered to actually read the links? And then lecturing me that people might take the wrong spin on it? Please!
I don't understand how you can read Linus' response and think "Linus regrets merging bcachefs" is an unfair assessment.
I'm trying a combination where I have an SSD (of about 2TiB) in front of a big hard drive (about 8 TiB) and using the SSD as a cache.
SSDs are more about latency than throughput. (And who wants to deal with five spindle drives in a desktop computer?)
In any case, in my case I had the SSD first and bought the HDD to expand my storage capacity.
I don't know whether your use case cares about latency, or about the number of drives. Your trade-offs might be different from mine.
Yes SSDs in theory are faster but you are only as fast as your slowest link, which is the spindle drive. so that cache is a buffer only for frequently read data. in home environments they’re next to useless. in enterprises they’re certainly useful.
If you check the numbers I gave above, I have 2 TiB SSD and 8 TiB hard disk. My 'frequently read data' is basically all the data I care about accessing. The other 8 TiB is mostly for eg steam games I installed and forgot about or for additional backups of some data from cloud services, like Google Photos. These are mostly write-once-read-never.
And eg if I happen to access a steam game that's currently on the HDD, it will quickly migrate to the SSD.
My 'working set' of data is certainly smaller than 2 TiB.
Five disks are safer than a single disk (if you store things multiple times or with erasure coding), but if you stick all five disks in a single device, the safety gains are rather more limited.
> Five disks are safer than a single disk (if you store things multiple times or with erasure coding), but if you stick all five disks in a single device, the safety gains are rather more limited.
There are devices called storage servers or NAS. this idea of not putting more than one spindle in a machine is foreign to me.
I probably won't use bcachefs until a similar level of adoption/community support exists.