From owner-freebsd-fs@freebsd.org Wed Jun 3 20:22:43 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 6456E2F23D6 for ; Wed, 3 Jun 2020 20:22:43 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49cgM62Kb4z4c6Y for ; Wed, 3 Jun 2020 20:22:42 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest-mbp.local (unknown [IPv6:2001:67c:708:101:1c00:9c12:f1ad:361d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id BECB0307F8 for ; Wed, 3 Jun 2020 20:22:31 +0000 (UTC) Subject: Re: fsck this shit To: freebsd-fs@freebsd.org References: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> From: Jan Bramkamp Message-ID: Date: Wed, 3 Jun 2020 22:22:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 49cgM62Kb4z4c6Y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-2.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.68)[-0.679]; DMARC_NA(0.00)[rlwinm.de]; NEURAL_HAM_SHORT(-0.43)[-0.427]; NEURAL_HAM_MEDIUM(-0.67)[-0.674]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] 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: , X-List-Received-Date: Wed, 03 Jun 2020 20:22:43 -0000 On 03.06.20 22:18, Thomas Mueller wrote: > 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. Yes as you can see in the MX records its run by a bunch of well known racists and faschists who also brought us nice domains like hitler.rocks, nigge.rs. nuke.africa and rape.lol.