From patchwork Tue Aug 2 13:20:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Mahoney X-Patchwork-Id: 9257299 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E00D760754 for ; Tue, 2 Aug 2016 13:20:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D124428525 for ; Tue, 2 Aug 2016 13:20:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C5E242852F; Tue, 2 Aug 2016 13:20:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from oss.sgi.com (oss.sgi.com [192.48.182.195]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 3E97428525 for ; Tue, 2 Aug 2016 13:20:33 +0000 (UTC) Received: from oss.sgi.com (localhost [IPv6:::1]) by oss.sgi.com (Postfix) with ESMTP id 4E11B7CAE; Tue, 2 Aug 2016 08:20:32 -0500 (CDT) X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B34CA7CA7 for ; Tue, 2 Aug 2016 08:20:30 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 7EF6F8F8035 for ; Tue, 2 Aug 2016 06:20:30 -0700 (PDT) X-ASG-Debug-ID: 1470144026-0bf57b369c349900001-NocioJ Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id ZyqTAH5fprQGkLWm (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 02 Aug 2016 06:20:28 -0700 (PDT) X-Barracuda-Envelope-From: jeffm@suse.com X-Barracuda-Effective-Source-IP: mx2.suse.de[195.135.220.15] X-Barracuda-Apparent-Source-IP: 195.135.220.15 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4EA69ABC9 for ; Tue, 2 Aug 2016 13:20:26 +0000 (UTC) To: xfs@oss.sgi.com From: Jeff Mahoney Subject: Old bugs in xfsprogs? Message-ID: <7e185931-8830-5f31-7abb-5419bb255991@suse.com> X-ASG-Orig-Subj: Old bugs in xfsprogs? Date: Tue, 2 Aug 2016 09:20:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 X-Barracuda-Connect: mx2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1470144027 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-ASG-Orig-Subj: Old bugs in xfsprogs? X-Barracuda-Scan-Msg-Size: 2566 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.31691 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: xfs@oss.sgi.com X-Mailman-Version: 2.1.14 Precedence: list List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com X-Virus-Scanned: ClamAV using ClamSMTP Hi all - While investigating a weird report on an internal list I found a few old commits that don't look quite right and that may be very old bugs. I know it's hard to go back nearly 15 years, especially in the days where very short commit messages were still acceptable, and try to remember why certain changes happened. In this case, a weird corner case[1] would've been caught, xfs_repair would've bailed, and a file system may have survived (despite obvious user error). 1/ Commit 5000d01d212f (white space cleanup) This one may well have been intended as a repair operation or perhaps it was accidentally duplicated from another chunk in the patch. At any rate, it hides a mismatched UUID between the log and the superblock from the rest of xfs_repair. The user sees the "error" message but it carries on anyway. 2) Commit d321ceac8da (add libxlog directory.) I believe this was supposed to be as simple as pushing some functionality from logprint into a new libxlog library, but the result is that things that used to return an error no longer did. The print_exit global that was initialized to 1 in logprint is initialized to 0 in libxlog and never set. So we always print an error message but then carry on. So even if the header_check_uuid() call above would fail properly, the error is printed and then the error condition ignored. -Jeff [1] The details are still murky, but what I got was that the user ran xfs_repair -L (yup, i know) on an image file that contained partitions. It found a valid XFS superblock and then "repaired" the file system to an empty state since everything it found was "corrupt." I suspect that there was an XFS file system on the raw image file, which was then partitioned without clearing the MBR, and the expected XFS file system was created on the first partition. xfs_repair was pointed at the whole image file, discovered the old superblock, and remade the fs in its own image since nothing was at the proper locations. diff --git a/libxlog/util.c b/libxlog/util.c index 7aca165..aa3093d 100644 --- a/libxlog/util.c +++ b/libxlog/util.c @@ -49,8 +49,10 @@ header_check_uuid(xfs_mount_t *mp, xlog_rec_header_t *head) printf("* ERROR: mismatched uuid in log\n" "* SB : %s\n* log: %s\n", uu_sb, uu_log); + + memcpy(&mp->m_sb.sb_uuid, head->h_fs_uuid, sizeof(uuid_t)); - return 1; + return 0; }