@feld (Yes, I *am* going to repeat that entire message verbatim every time someone tries to tell me zfs doesn't need fsck because it has scrub.)
Zack Weinberg
@zwol@masto.hackers.town
Nerd of all disciplines. Online just barely long enough to remember USENET.
Analog interests include pottery, candlemaking, board games, science fiction and fantasy, photography, and cooking.
New follows welcome, but I probably won't follow back because I can't keep up as is. Also, if you are on a large instance please fill out your profile first so I can tell you aren't a spambot.
Posts
Latest notes
CPU architecture in which all instructions that access data in memory *require* you to specify the byte order of the value in memory
CPU architecture in which all arithmetic instructions require you to specify both rounding direction and behavior on overflow (overflow options include "wrap", "saturate", and "set a carry flag", but NOT "trap")
CPU architecture in which each register is extended with the standard set of arithmetic-result flags (zero, negative, carry, etc), which are set by anything that writes that register; conditional instructions can read these flags from any register; thus splitting the difference between "one flags register" and "predicate bits" architectures
CPU architecture in which there are no asynchronous interrupts, only hardware tasks that can be suspended waiting for an external event
@david_chisnall I recall microkernels having similar problems with offering flexible scheduling policies, so that research seems like it might pay off in a bunch of directions.
@david_chisnall I have the impression Spring's solution rests on "doors" being synchronous. If I designed a microkernel it would be strictly asynchronous: all cross-domain invocations "just" queue a message and the *only* blocking operation is "wait for next message". Backpressure is achieved by charging senders for all messages in flight. I *think* this environment could handle priority inheritance by tracking the task priorities of all unacknowledged messages.
@feld Indeed, I wasn't the only person affected. I don't have a link to hand, but it's in FreeBSD's bug tracker somewhere. This was roughly four years ago, if that helps.
@feld (For maximum clarity, by "inaccessible" I mean the files showed up in a directory listing but open() would return ENOENT.)
@feld I don't know what a MOS is, but the root cause of my problem was not hardware-level bit rot; it was a logic bug, that caused the data structure on disk to be semantically incorrect, *despite* all the checksums being valid, in a way that rendered a whole bunch of files inaccessible.
I don't *care* whether a manual recovery would have been possible somehow. If it had been *any other FS*, fsck -p would have fixed it. zfs has no true equivalent of that command. That's all that matters to me.
@feld zfs scrub does not validate or correct the on-disk data structure, it only checks the block checksums. That's what I mean by "doesn't have a *real* fsck."
The data loss I experienced was due to a buggy migration of the on-disk data structure. All the block checksums validated, but files became inaccessible. Scrub did nothing. A real fsck might have dumped a bunch of stuff into lost+found, but that would've been enough to avoid having to restore from backup.
@djfiander @mwl @b0rk if you actually do a zine about ZFS please make sure to mention that it doesn't have a real fsck, and yes, this can and *has* caused data loss in production.
to me. personally.
not that i'm bitter.
not that this wouldn't be an unforgivable act of hubris by the zfs developers even if it had never caused anyone any data loss even in testing, either.
@tante I can't remember where I saw this but I saw an essay recently arguing that a lot of people had such negative experiences with primary education that being asked to learn anything new is effectively a trauma trigger.