Egregoros

Signal feed

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

Poll (single choice)
yes
8 votes 27.6%
no
19 votes 65.5%
better idea:
2 votes 6.9%
29 votes total · 29 voters Poll ended

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")

Poll (single choice)
yes
16 votes 80.0%
no
3 votes 15.0%
better idea:
1 vote 5.0%
20 votes total · 20 voters Poll ended

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

Poll (single choice)
yes
13 votes 68.4%
no
6 votes 31.6%
better idea:
0 votes 0.0%
19 votes total · 19 voters Poll ended

CPU architecture in which there are no asynchronous interrupts, only hardware tasks that can be suspended waiting for an external event

Poll (single choice)
yes
12 votes 66.7%
no
6 votes 33.3%
better idea:
0 votes 0.0%
18 votes total · 18 voters Poll ended

@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 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.