From owner-freebsd-fs@freebsd.org Tue Jun 2 21:46:47 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B56182FBC0E for ; Tue, 2 Jun 2020 21:46:47 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from p-impout001.msg.pkvw.co.charter.net (p-impout008aa.msg.pkvw.co.charter.net [47.43.26.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49c5GZ0Qmqz3d9t for ; Tue, 2 Jun 2020 21:46:45 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from localhost ([96.28.177.163]) by cmsmtp with ESMTP id gEk2jb7b9rzR3gEk2jlvp3; Tue, 02 Jun 2020 21:46:39 +0000 X-Authority-Analysis: v=2.3 cv=Ne6YKFL4 c=1 sm=1 tr=0 a=xqrt2BZAGHte7XHhrxJgbA==:117 a=xqrt2BZAGHte7XHhrxJgbA==:17 a=HpEJnUlJZJkA:10 a=DBwwDor5xuMA:10 a=qz5MpHPoCsHZqr7YxSUA:9 a=FIdtiwb641T6Oyvz:21 a=qQn6kh7PZddSMNYG:21 a=pHzHmUro8NiASowvMSCR:22 a=n87TN5wuljxrRezIQYnT:22 From: "Thomas Mueller" To: freebsd-fs@freebsd.org Subject: Re: fsck this shit References: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> X-CMAE-Envelope: MS4wfBBGzuUdMJRB77oD2rsmspRCa2MiPVVGftU7BlqmgBNIYNwd8Yc16L/V6W2jOiLM7w4rT8lkYi0AzjSgGMNniwpet0l/85hHeay+nkb+nTaecyq3v5NQ f53BSY2BEt7kd0gNl2tQET+N3mrtFyHb50ZqmeJtXHoNTnxJMwzWGzUgAitZ6FfpENDEVoyMrz+6wkIN0P7BssHhQlrROs21onr0/z11q5WmRHLdQVis3okJ X-Rspamd-Queue-Id: 49c5GZ0Qmqz3d9t X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mueller6722@twc.com designates 47.43.26.139 as permitted sender) smtp.mailfrom=mueller6722@twc.com X-Spamd-Result: default: False [2.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.54)[-0.542]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[twc.com]; MISSING_DATE(1.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[twc.com]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; NEURAL_HAM_LONG(-0.11)[-0.110]; MISSING_MID(2.50)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.04)[-0.043]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[twc.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.28.177.163:received] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 02 Jun 2020 21:46:47 -0000 X-List-Received-Date: Tue, 02 Jun 2020 21:46:47 -0000 from goatshit54108@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 GAAAY. > 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=, cleanup=) at crt1.c:76:7 > Some analysis: (snip) 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 52.11.159.5 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. Tom