They did, apparently, at one point pay someone to build that glue, and then threw it out and wouldn't let the author release it so he's been reimplementing it out of...spite? Burning desire? Unclear. [1]
I can't imagine the logic involved in "this is implemented, let's toss it in the dumpster" for that.
Drives sometimes are worse at their internal error detection than you might hope, and might return incorrect bytes.
You might have faulty hardware flipping bits between when you computed a checksum/parity/etc over your data and when you wrote it out, either in memory, or over the wire.
You might have a software bug or an interaction with a hardware erratum that causes the CPU to misbehave and mangle your bits in certain cases, maybe around switching from running code in a VM to not and back.
You might have had, say, the Samsung HD204UI hard drive, which loses data after it tells the OS that it's written because of a bug around its write cache, so you get no error back, but you go to read the data back later and it's actually whatever was there before you tried overwriting it.
SSDs, NVMe and otherwise, _can_ fail in ways that aren't just vanishing from the bus, it's just much less common than with mechanical drives, IME. I have sometimes seen SSDs return incorrect bytes inconsistently or consistently, or start spitting up read/write errors rather than entirely vanishing from the bus.
Each of the above examples is a real thing I saw happen. None of them is particularly likely, plenty of people never have dumb shit like any of that come up. But it's not never.
- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance
- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage
Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...
But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.
I felt the same way about it as you before I started looking for benchmarks as I wrote my previous comment. :)
After all: Why would zvols exist at all if they weren't superior in important ways?
> it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance
It's important to note that additional datasets are essentially free on ZFS; it's no big deal to have lots of them (millions of millions of them is A-OK), and datasets don't have a pre-determined size like zvols do.
Although zvols can also be grown and shrunk, just as files [within datasets] can be.
Both datasets and zvols make the same kind of mess out of zfs list's unfiltered output.
But zvols introduce a new concept, while anyone who uses ZFS is already familiar with datasets that contain files.
I think this part is a wash, and that it comes down to operator preference.
> avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage
Maybe? Again, the benchmarks I found (hours ago now and tabs long-closed; I'll find more if anyone insists) suggested that files were faster than zvols, which suggests reduced overhead. (It's very possible that the tests I found were naively implemented, but then: It's also possible for any of us to do something naive.)
Anyway, it's interesting to think about.
It seems like the right answer is to test with one's own workload and find the best fit, instead of assume that one way is better than the other.
For its part, ZFS should handle a zvol and a file-on-a-dataset with equal stoicism and reliability.
Sure, I'm not suggesting that they're a good idea to use blindly at this point - I think most people are building on filesystem-based setups so most of the polish is going there.
But that was the original logic.
I also would be curious to see benchmarks for them on FBSD and Linux, because FBSD and Linux (the platforms at large) diverged in how they handle "disks", with FBSD opting for only character devices (unbuffered) and Linux only block devices (buffered).
I think the problem isn't that competition needs to be an order of magnitude better, it's that if places have exclusivity agreements, it doesn't matter how much better you are.
The comment in [1] also outlines a bunch of reasons it's extremely difficult to break into.
In this particular case, I think the point is less 1 or 2 but more point 3
(3) the contrapositive, where you continued the flight, it really was someone stupid enough to name the broadcast name of a bomb "BOMB", it goes off, and now you have to explain to the press "we thought nobody would be stupid enough to really name it 'BOMB'"
So you assume it's a low risk event, and tell everyone onboard to turn off their devices to remove the chance it's just someone making a bad joke or a coincidence, and then you end up with the outcome of trying to avoid having to say that in a press conference where everyone is already primed to think you didn't do enough.
That makes absolutely no sense. As the previous comment pointed out, turning around is not treating it seriously. If you are trying to save face in the extremely unlikely event that it is real, then the only thing you can do is head to the nearest airport.
1) If it really was a bomb and went off, the pilot wouldn't be there to explain to the press anyway.
2) How likely would a bomb's name really be "BOMB" vs anything else? If the latter is any higher, wouldn't it be reasonable to always turn around whenever the any other name shows up? In that case, all Bluetooth devices should be strictly banned in the cabin. But TSA is not doing that (not yet).
Americans think they're "free and democratic" in the same way that aristocrats think they're better than everyone - it's been inculcated in them since birth, by every aspect of the culture and their upbringing, and as an axiomatic belief, it's not something they challenge.
There's nuance, of course, with people who are worse off in America seeing some cracks in it, but that's how you get the idiom about "Americans vote like temporarily inconvenienced millionaires" - they are so convinced the game isn't rigged against them that they vote assuming they will win at the casino one day.
There exist a great many people in the world who think that the only important thing is having a good enough idea, and everything else is almost valueless by comparison. You've probably met them, people who say things like "I just need someone to code it, can you sign this NDA, what do you mean you want to be paid, it's just coding?"
They exist in other formats too - blogs in the vein of "for exposure" cover the same premise, mostly.
Vibe coding has allowed them all to try and show everyone how right they were.
Right, but most of them don't already work as software engineers, at least it hasn't been my experience of my colleagues. However, companies that are aggressively adopting AI coding tools aren't (at least nobody has shown it) getting better by any metric. So, what gives? Why, generally, isn't this kind of success story common?
Because most tasks aren't "refresh this code from 10-20 years ago"?
If you needed an old piece of code at $WORK, you probably already paid the tax of refreshing it or replacing it.
This sort of task is similar in nature to something like "I have a 25yo unmaintained Linux driver, let's refresh it for modern Linux" - a great demonstration of the efficacy of these tools if you have the right-shaped task, but not a task that comes up repeatedly in most people's days.
That's a good point, this does seem qualitatively different. Like dialect translation. In that case the specification is really precise, it's just the old code. Building something new or adding functionality to existing software the spec is almost guaranteed to be more vague.
EDIT: this specificity seems important for language models but the harder I think about it the less sure I am that it's the right intuition..
My intuition is that what makes them well suited is that the transformations on the input desired are well-defined and frequent tasks - e.g. any other software that migrated from, say, SDL1 to SDL2, or had to move from gcc 3 to 4, or Sun cc to gcc, had to have these transformations in their source history.
IOW, "there is probably very little stopping you except time from having written Coccinelle patches to mechanically do most of these transformations".
I've been trying to use it for a massive tree of ~250k files across ~500k folders, which only needs to live on one device at a time and sync to a backup in case it dies, and even if I tell it send-only/receive-only explicitly, it regularly seems to go cross-eyed at some change made in the folder structure and give up and rescan and hash everything, and if anything in the tree changes while that's happening, it gives up and just marks it a conflict to be manually resolved...or silently hangs until I restart it.
It's working well for me (as in totally hands off for months or even years at a time) at (I think, roughly) a few hundred thousand files but probably significantly fewer directories. Overall I'm really impressed and happy with it. But this is just personal file sync, nothing too demanding and unlikely to hit edge cases with concurrent edits etc.
They say pretty directly in the post that they didn't want to deal with the hassles around dongles and uncommon ports for using this as a Linux PC in their pocket.
Imagine you check into a hotel, and want to use the in-room TV as your display. There is probably a set top box there with an HDMI port going to the TV. You would be able to unplug that and plug it into your Flipper One because it has a full-sized HDMI port.
Go to any store, and look at what cable they use to connect their POS computer to the display. It's probably HDMI.
For better or worse, HDMI is extremely ubiquitous.
[1] - https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
reply