Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1644553imm; Fri, 14 Sep 2018 23:58:40 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYuc5VGtqNdqt0GWmI9hCUtn2WhNHr9L451P29JUJgMbFc8PLMRxsnqY7T10AcXcBojaOUc X-Received: by 2002:a17:902:b7c5:: with SMTP id v5-v6mr15652059plz.49.1536994720095; Fri, 14 Sep 2018 23:58:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536994720; cv=none; d=google.com; s=arc-20160816; b=FIeY8voHYQ5pPB5ap42JBylR57mnjmRUEbhSEv6fi0ZGQJk/A2Rjy2J2YB1qYU0CSD 368gd4g5zAUd++o4h3Yb/paPAW6fzt98XehekbBCXcxoZLLjCBVKDWipsaruI6TYQ0e4 iDYEa5VhVEaYot7J0Bxbhdl3NJ2QdRBFVF7fh8f0X2qHZ5/l0RCd2dH56DUk+cIbHGgJ V1YrYm8wSipj48//mb+8ksFq+AZrHCfJ6gJbMHXuqZHBkYByKLHVH0waa6o2TllArOt5 xwpFMJ0DvN/hiD2wXbkN0OnV27jxrCuR5rJj0rUz6kSkrBLh614SysWbpFcYsflpW/hD AdsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=QfDYA0yl/YE9INDs2s5RGeG32jzODQuXrSzcv9liAmc=; b=MHxYihzm4ZFd14ZXLAgatdKIIlBFdo2EMPn9SG43UQal9t0DMxnihmejaYMgW6ZuHo fp+di7uPPJE0thHCZALxnOToowkEG5/J22zt2vcYN9dEv+aWtyVQxoEwFJhR0c+t+cQT BS4SsIhEZeCyJ4BgVjOMSe095TKvF6sByfsMoOEHwosWrFfOidS1IMMXuc56gDdr2Zph r87WCMSuylbfpv84j8l9bWyQtK3jLVREzFSZd8esA9XgUPO0dtVRYlbtxsAp1wze8zzC yLbsoFqdeOP6yh+tZLeH1X5xDPA7CHP6IjJ3IIfXi/fKxRYeWZXOrDuuHS/aum/kd/qw AhGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kczB4eTf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r7-v6si8159379ple.309.2018.09.14.23.58.24; Fri, 14 Sep 2018 23:58:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kczB4eTf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727798AbeIOMQP (ORCPT + 99 others); Sat, 15 Sep 2018 08:16:15 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:39945 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726383AbeIOMQP (ORCPT ); Sat, 15 Sep 2018 08:16:15 -0400 Received: by mail-oi0-f67.google.com with SMTP id l202-v6so14765712oig.7; Fri, 14 Sep 2018 23:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QfDYA0yl/YE9INDs2s5RGeG32jzODQuXrSzcv9liAmc=; b=kczB4eTfclIBGzSAJJPlLeJNwTo4shMO8kqtVE5U4vzaZwaFocVtvOCxFGy5r1ZO4N ghiZ9/oUftWQeyG568Nh20jjyAYPaaPAYj+Mh37hkXoUlkyqyPa0g1DB4sIQlWnLLEJt GyalDdxg/Zu50+BvcA/nUDYg0UnVoTN8aBFRglZ0e2puUKNsjSkufrYVobYxBhMTkYd1 L5HyfQCBKEsi1FpiE64O4ikxseVUH7f6f3PiLWtz4c8J6r+pcPX8Cozd1NyuiAhkHrTM UfLhVXkMR1VFQnuUjv96PL7xNKlsfli4VVBVj2dXX+eXKMideO7XgbOiFhVUtoxPMHei atyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QfDYA0yl/YE9INDs2s5RGeG32jzODQuXrSzcv9liAmc=; b=ocnD39AC1zpalszm3onxtmCv6bZ98t38BLODQezRiPbxQPafsw5Y05WaduxDxpyj7q kY7tJZLlGtiGQ8kLrYOJTHDeRZ7FyzW6eF6/5Rci7zIjwOBlyTzSIShuK3at4cbnBKu9 ky3U6yq3oubAAN8M4+Tu6A7e9XsF+B6dJECLb4GnJvz6GTkILxyGn2tA+BQeRC8ld4jo XyS0iLcN1Wx4g+x7E7I7erhs3cj5hfBET6Ml3sc6DuyZsfPzxl6A2Xty0z45g0uTtS1d Qm0IJWBVU+yHMxJinGBerMTNtXn98QPYZV8/15ca4t1P3A5m6IQTW499pTUqJ/BBzLit /dcA== X-Gm-Message-State: APzg51CEpowluMsvxZ3nyxWiML+LaHnroDqt2luvh5WL6nKRzq2YwcfP K7NU2L+fcq096IrjSfT8ylEQRrlWsYD/wdhSpnqHJrBkkM2G//Ua X-Received: by 2002:aca:3c02:: with SMTP id j2-v6mr11890771oia.50.1536994698825; Fri, 14 Sep 2018 23:58:18 -0700 (PDT) MIME-Version: 1.0 References: <20180914222336.GD16550@dastard> In-Reply-To: <20180914222336.GD16550@dastard> From: =?UTF-8?B?54Sm5pmT5Yas?= Date: Sat, 15 Sep 2018 14:58:07 +0800 Message-ID: Subject: Re: metadata operation reordering regards to crash To: david@fromorbit.com, cmumford@cmumford.com, linux-btrfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 15, 2018 at 6:23 AM Dave Chinner wrote: > > On Fri, Sep 14, 2018 at 05:06:44PM +0800, =E7=84=A6=E6=99=93=E5=86=AC wro= te: > > Hi, all, > > > > A probably bit of complex question: > > Does nowadays practical filesystems, eg., extX, btfs, preserve metadata > > operation order through a crash/power failure? > > Yes. > > Behaviour is filesystem dependent, but we have tests in fstests that > specifically exercise order preservation across filesystem failures. > > > What I know is modern filesystems ensure metadata consistency > > after crash/power failure. Journal filesystems like extX do that by > > write-ahead logging of metadata operations into transactions. Other > > filesystems do that in various ways as btfs do that by COW. > > > > What I'm not so far clear is whether these filesystems preserve > > metadata operation order after a crash. > > > > For example, > > op 1. rename(A, B) > > op 2. rename(C, D) > > > > As mentioned above, metadata consistency is ensured after a crash. > > Thus, B is either the original B(or not exists) or has been replaced by= A. > > The same to D. > > > > Is it possible that, after a crash, D has been replaced by C but B is s= till > > the original file(or not exists)? > > Not for XFS, ext4, btrfs or f2fs. Other filesystems might be > different. Thanks, Dave, I found this archive: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg31937.html It seems btrfs people thinks reordering could happen. It is a relatively old reply. Has the implement changed? Or is there some new standard that requires reordering not happen? > Cheers, > > Dave, > -- > Dave Chinner > david@fromorbit.com