fsck this shit

Thomas Mueller mueller6722 at twc.com
Tue Jun 2 21:46:47 UTC 2020

from goatshit54108 at national.shitposting.agency:

> Once upon a time, the power ran out, and then...

> ** SU+J Recovering /dev/<...>
> ** Reading 33554432 byte journal from inode 4.
> ** Building recovery table.
> ** Resolving unreferenced inode list.
> ** Processing journal entries.
> fsck: /dev/<...>: Segmentation fault


> OK, let's check the core dump... oh, wait... tough luck. Fortunately, subsequent runs of fsck ended up likewise, so I was able to get a core dump by re-executing fsck while being inside a TMPFS-backed directory. (On the other hand, unfortunately, fsck was never able to replay the journal.) Furthermore, I saved the .sujournal file, but saving the contents of the whole filesystem was beyond my resources. (It would have been adequate to use a tool that collected (only) the blocks that fsck read before segfaulting (thus constructing a small test case), but no such tool was at hand.)

> Before running "fsck -y" (because I had no other options) I looked at "fsck -n" to see whether a particular, large file would get idiotically removed as part of "fixing" the filesystem. This routine is prompted by (1) personal experiences of files getting lost or truncated to 0 length, and (2) past reports of disasterous behaviors involving soft updates, such as untouched (read-only) files getting lost; "lost" means not even relinked to /lost+found or anything. And wouldn't ya know it, fsck did ask whether to remove something that had an unambiguously large size (to be exact, IIRC: "DUP ... REMOVE?", whatever that means). That's it, either (a) remove the file, or (b) stay dirty; take it or leave it. It's not like there was some 3rd option to relink the file to /lost+found. After "fsck -y", the file disappeared without a trace. GAAAAAAAAAY.

> The fsck_ffs (or fsck_ufs) file was the one distributed with the 12.1-RELEASE, the one with the SHA3-256 checksum of 447592ae05dc7829823901700bb90940968cae006719964d39b1212bb312d164. Let's see the backtrace:

> * thread #1, name = 'fsck_ufs', stop reason = signal SIGSEGV
>    * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=10692928, mask=0, frags=134643471) at suj.c:653:34
>      frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=5296913, size=134610944) at suj.c:1547:3
>      frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined] cg_adj_blk(sc=0x0000000801574540) at suj.c:1788:5
>      frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined] cg_apply at suj.c:1900
>      frame #4: 0x0000000000216fa5 fsck_ffs`suj_check(filesys="/dev/<...>") at suj.c:2737
>      frame #5: 0x000000000020ef54 fsck_ffs`main [inlined] checkfilesys(filesys="/dev/<...>") at main.c:427:9
>      frame #6: 0x000000000020ef07 fsck_ffs`main(argc=1, argv=0x00007fffffffec48) at main.c:205
>      frame #7: 0x000000000020810f fsck_ffs`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

> Some analysis:

I have had times when fsck_ffs from FreeBSD didn't succeed, but fsck_ffs from NetBSD did succeed.  That was on a FreeBSD installation, but I also had/have NetBSD installed.

I use GPT with no traditional BSD disklabels, so FreeBSD and NetBSD can read and write each other's partitions.

I ran "host national.shitposting.agency", and got 

national.shitposting.agency has address
national.shitposting.agency mail is handled by 20 mx2.cock.li.
national.shitposting.agency mail is handled by 10 mx1.cock.li.

so the domain really exists.


More information about the freebsd-fs mailing list