From owner-freebsd-fs@freebsd.org Sun Nov 25 23:45:09 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D701111471A8 for ; Sun, 25 Nov 2018 23:45:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670082.outbound.protection.outlook.com [40.107.67.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEC347C8E1 for ; Sun, 25 Nov 2018 23:45:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM (52.132.50.155) by YTOPR0101MB1161.CANPRD01.PROD.OUTLOOK.COM (52.132.50.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.20; Sun, 25 Nov 2018 23:45:05 +0000 Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM ([fe80::9c71:6eb6:1bff:727b]) by YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM ([fe80::9c71:6eb6:1bff:727b%5]) with mapi id 15.20.1294.048; Sun, 25 Nov 2018 23:45:05 +0000 From: Rick Macklem To: Kirk McKusick CC: "soralx@cydem.org" , "freebsd-fs@freebsd.org" , "Julian H. Stacey" , Konstantin Belousov Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock Thread-Topic: [bug] fsck refuses to repair damaged UFS using backup superblock Thread-Index: AQHUhJlTgUa5G9TQ8USwP5697EmSSKVgmAwVgAA76wCAAFAAeQ== Date: Sun, 25 Nov 2018 23:45:05 +0000 Message-ID: References: , <201811251842.wAPIgEpW053136@chez.mckusick.com> In-Reply-To: <201811251842.wAPIgEpW053136@chez.mckusick.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1161; 6:cEkfQgWcfsMkz3EcZ4gAQ0ZdVeqOWK8w4SKdWbkE/z7aRx039QqSDWdXgpJ4ZZ/0HAJ2dzfnP8keYt8PdRtimCk7WVUn2sG7krw9Wu+Wa6RgyIUcyblgt+13HhDxCiBKtF1c0wL0ysKmMSmU3nHAMFacwQctKnlrg3Nb093fgXO8LBOFwWDnD8hRbekXJoWUG1uZ50pBbzRrlfTT5o2IdVFQhfpxZ5Qak3zSUStJXAsF/N/AIcl8SAngZES4Ltuy4PY/FYJbU0s2H3ZgS90vkDLkwtKfr/mheTM6auT5jGXXbIZwu5e+Gmp9p4MUvORgxwKsFsdBhrmx411hElj7caIUk/n5L3iXwPIbEltiKv2NlaM+gQ3lEZXCLCKjmlrUweccAVANcpXwpQGKCW85mikXOA5yws+PWHao04EgXVukNbFmsDeROAkp+oP+nEFsgxNLKzxhr2OtPlqgeyn4RQ==; 5:k6LRq+s/9kzwNOgafmQRZX0R1/rxmDnm0gWVMp4529Ziih8MlMF7J/5ql3aYFjz78ozUYSvs4QwV+jCwZx5TqIIX80WdhlSpIZxx0Y44eWnZOEd0v9hpsHdev1CHWnt6SlQrjVcRH3+5ngcS6jrhuQ1k/29lwtDlZRk7GE5hAnQ=; 7:kD73mDHjeHeLtp+SLbKpHYBOBKu/86E3AZ3sNtxkYKGfYc8xhyJme0vAesYTaw9sNzA/QLp6TdZNTJq3RtMDOA3yH43mNq6UfY8g4dkqOeyslXicwV12ZvrbAJ0giLCSe3pLAjwVJbbDZFCcmDdUDg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dec99de5-e6ec-4815-48c3-08d653300677 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1161; x-ms-traffictypediagnostic: YTOPR0101MB1161: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231442)(944501410)(52105112)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB1161; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1161; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(366004)(376002)(39860400002)(189003)(199004)(7696005)(9686003)(76176011)(446003)(476003)(33656002)(55016002)(11346002)(25786009)(8936002)(229853002)(8676002)(81166006)(305945005)(6436002)(81156014)(74316002)(316002)(786003)(486006)(54906003)(5660300001)(99286004)(105586002)(53936002)(6246003)(478600001)(68736007)(2906002)(186003)(46003)(86362001)(6506007)(39060400002)(4326008)(74482002)(6916009)(14454004)(106356001)(256004)(102836004)(71190400001)(14444005)(97736004)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1161; H:YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: sEXOEzoHM326PLZeDvCtbXQffQfrxcbgZHMj+Ok61t2UUaLfVspXcAG+dcrILZzmKg/Q6WJNu3l1pIeM2qcG6M0EefV80jQkZEhKVvjymW/b/e2ZzTY2mUxQXyjTVXp1kJFXwqgZS6YPR516GpviCD3ZHNui8aJCJu+5p+YAxL9/YKHlfQzp5ejB90CHgeYFj876mZNSujrkFhg1uUtvC7PseytjAESsyRzl7jJyXriuLPXQnBlEm/imdZ6AjnCFtVyB4pYTAr923xVdiSjPP+Ol/IYG/O5ZPqDBlJmIHsdx4arPKSItNOBiV+Pe51THcxn7srmbW9RJC7GbstIma+l9J06e18BJRcduAgOkskw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: dec99de5-e6ec-4815-48c3-08d653300677 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2018 23:45:05.0379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1161 X-Rspamd-Queue-Id: AEC347C8E1 X-Spamd-Result: default: False [-4.08 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; RCVD_IN_DNSWL_NONE(0.00)[82.67.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; IP_SCORE(-0.83)[ipnet: 40.64.0.0/10(-2.12), asn: 8075(-1.92), country: US(-0.09)] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 23:45:09 -0000 Kirk McKusick wrote: >> From: Rick Macklem >> To: "soralx@cydem.org" , >> Kirk McKusick >> CC: "freebsd-fs@freebsd.org" , >> "Julian H. Stacey" >> >> Subject: Re: [bug] fsck refuses to repair damaged UFS using backup super= block >> Date: Sun, 25 Nov 2018 15:25:21 +0000 >> >>> Kirk McKusick wrote: >>> >>> Below is a proposed fix for fsck_ffs to properly handle superblock >>> check-hash failures (notably to optionally search for a usable >>> alternate superblock). Let me know if you still have a filesystem >>> on which you can test it, and if so whether it works correctly. >> >> As above, I think you can reproduce this by running an older kernel >> that mounts the file system. I ended up re-installing when I ran >> into this yesterday (no biggy, it was just a test machine). It >> happened after I had been running a kernel built from stable/12 on >> the system and then tried to boot it. (Since the root fs got these >> errors, I couldn't boot any kernel on the root fs.) > >Kernels before -r339671 clear the CK_SUPERBLOCK flag in the superblock. >Kernels at and after -r339671 ignore the check-hash if the CK_SUPERBLOCK >flag is clear. So you should be able to run on older kernels without >causing superblock check-hash failures on later kernels. Fsck will offer >to enable the superblock check-hash if you are running on a kernel at >or newer than -r339671. Not if the kernel is stable/11 (I realized that was what I booted that tras= hed the machine). For stable/11, fs_metackhash is just fs_sparecon32[22]. I'm guessing that fs_sparecon32[22] happened to hit memory with CK_SUPERBLOCK set in it when the superblock was written by the stable/11 ke= rnel. Then the file system had a bogus checksum when trying to boot it beca= use fs_ckhash was just random garbage written for fs_sparecon32[21]? Maybe setting all elements of fs_sparecon32[] to zeros before writing the superblock out would minimize these issues for the future and could be MFC'= d. (I'm not claiming that a new FFS2 should be movable between stable/11 and head, but it might be a nice feature?) >> It would be nice if there was a way to override the check and boot >> the system. (Is a loader tunable reasonable for this?) >> >> rick > >I have fixed the problem with fsck being unable to check filesystems >with check-hash failures in -r340925. > >Rather than adding a loader tunable to override the check (which people >would have to track down in the midst of a crisis), it might be better >to simply have the loader print a warning when there is a mismatch and >proceed to try using the filesystem. If successful, an fsck could then >be run to try and clean it up. Does this seem reasonable? Yes, that sounds fine to me. rick