From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E198C3A59F for ; Thu, 29 Aug 2019 23:51:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DA5262189D for ; Thu, 29 Aug 2019 23:51:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726416AbfH2XvA (ORCPT ); Thu, 29 Aug 2019 19:51:00 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:34998 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726369AbfH2XvA (ORCPT ); Thu, 29 Aug 2019 19:51:00 -0400 Received: from mail-io1-f69.google.com ([209.85.166.69]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1i3UBu-0001yj-7H for linux-fsdevel@vger.kernel.org; Thu, 29 Aug 2019 23:50:58 +0000 Received: by mail-io1-f69.google.com with SMTP id t8so6001127iom.8 for ; Thu, 29 Aug 2019 16:50:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3bplvyURywyrZUbCnQRJbRY3iQ4HwcWNIDQydpGaXzw=; b=kGmzErBnfOK1F41gUXQ6vlM4ap9S0wBrKTVPyyciyBiTn/75MfBaLwEmLVURs9Ns8l g77rho2A2SVpd7LlK++8FnV1Q2Jbp8ZfpnsdswBSaTjRnQNTO/91aFampcJ5pMeCufwg 9RCqgErc8OX9omjHyUvaRTbS0EHDJI1DtURJVqFa/g7zGLb63iCQJGfFjQ/Vs3IIh9MZ 2+JEarvWC5Bb0pKlWnBB4iPpQ7r3CJMC9HybMQuFX2AqdJtJP83rOx95SPphO/S69QEu BLpsFngHaB6887vTy2wOXqiQ4A2NqbtPu5D+Ff5O3RmRz3WHUhTd5GFND9tRVEauMs2q 7Msg== X-Gm-Message-State: APjAAAWqlHYkf+CLhDJ718JFy2ae4lx68N6glS7cwahmJlOx/DMUWND+ hTkOMcihQwp1RxYaNOVVx5Nbszf3L1Ex2cppRVJ4HNqMF1Dho+WbThaHLRJtXDtHiFgR40OghVA RegYe3jlplLO43lbRgndP6Idhm4jQwFBp08NDStxgThE= X-Received: by 2002:a5e:c601:: with SMTP id f1mr1460473iok.57.1567122657091; Thu, 29 Aug 2019 16:50:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVuQnZ/cvr+tJx6ohprUk+vQVxjt8IJle6PnfnhhWSHmODgvICpS6ziu4ipRwqPguJYD5bpQ== X-Received: by 2002:a5e:c601:: with SMTP id f1mr1460442iok.57.1567122656802; Thu, 29 Aug 2019 16:50:56 -0700 (PDT) Received: from xps13.canonical.com (c-71-56-235-36.hsd1.co.comcast.net. [71.56.235.36]) by smtp.gmail.com with ESMTPSA id v12sm3744576ios.16.2019.08.29.16.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2019 16:50:55 -0700 (PDT) Date: Thu, 29 Aug 2019 17:50:54 -0600 From: dann frazier To: Eric Sandeen Cc: linux-fsdevel@vger.kernel.org, Theodore Ts'o , Jan Kara , Colin King , Ryan Harper Subject: Re: ext4 fsck vs. kernel recovery policy Message-ID: <20190829235054.GB13045@xps13.dannf> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Aug 27, 2019 at 03:29:09PM -0500, Eric Sandeen wrote: > On 8/27/19 2:10 PM, dann frazier wrote: > > hey, > > I'm curious if there's a policy about what types of unclean > > shutdowns 'e2fsck -p' can recover, vs. what the kernel will > > automatically recover on mount. We're seeing that unclean shutdowns w/ > > data=journal,journal_csum frequently result in invalid checksums that > > causes the kernel to abort recovery, while 'e2fsck -p' resolves the > > issue non-interactively. > > > > Driver for this question is that some Ubuntu installs set fstab's > > passno=0 for the root fs - which I'm told is based on the assumption > > that both kernel & e2fsck -p have parity when it comes to automatic > > recovery - that's obviously does not appear to be the case - but I > > wanted to confirm whether or not that is by design. > > > > -dann > > Ted or others more involved w/ ext4 will speak w/ authority but it's my > understanding that log replay, whether done by userspace or by the kernel, > should always return the filesystem to a consistent state. If that's not > the case, scripting things so that you grab a qcow-format e2image prior > to fsck so that you can share the problematic image with developers may > help. Thanks Eric. I captured an image in case it's useful: https://people.canonical.com/~dannf/md2.e2ic.qcow2 -dann > > (In XFS land, a large portion of the unreplayable logs we see are the > result of storage that didn't /actually/ persist IOs that it claimed were > persisted prior to the crash/poweroff.) > > -Eric