Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1312375imm; Fri, 14 Sep 2018 15:25:31 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY0qzEOLN73L2wL8uj7XdTKCltg7cFYOErNrl/TWg6pVOKrOI5Hmyg0n09dZl2Sae2bol+B X-Received: by 2002:a63:fb07:: with SMTP id o7-v6mr13585442pgh.333.1536963931777; Fri, 14 Sep 2018 15:25:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536963931; cv=none; d=google.com; s=arc-20160816; b=qqYhzkunLo0Y+dXJ/I/PhVenDB5D5i6bGATUFb47HEcB2Eu379MZbyJwx30BTfIapj I3JzDeC/LmWx1yGbdjcE1H2tAbYPMWVYjzbQk7kLfNY5NuVQbPyycxeJNDbl9ZpDnLqt m+wl6faIwyOaRdtmqUMJIiNWlCkddM3wrT82zVI+URIuLx0t6m0FThGZfM614x6YYswp Mr+PrB1rnfukf10eq8FJEz41hE39x2yKWnAzmToHaJJP611p8UC8q57GD6gIAY89OSEG gsodCKJnjpckKMmQnmIVdi4AT92iMc1SMAdkJo3mZPGFrVMOtXb/Un9g4nGxomAU1Lg5 ompg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=kgFO9C3Ve0R6dfBtACYjdN6fEBwB99aEyWBLYsM6LBQ=; b=ZeL0a5zS40GkHyCaW4JM3MUg55uVNBxDBFrrkypK3P4IvaeLXMSqFrESbVGCKotsY+ pcQFZjPVk/ZoXv1skLF99euRqynN2RnfypEVPV2TuJ1Wr0QE+ur0tVqNQwa0UlvxjMqp HZoDdUfkcrF5TuqjiQbv/vIRiPzRvtc9bnJr8fe6mEc9CUewuLzD9Px4mq+MxNIridDu 4CV+VFdsPbA+2Mqk3SjMIpFwdMRPfW2AyqvwiAxBItRyswo9BIkjQrlmQCSRauvb/oJV XR/18A6Zmb86rxkvkQeQLTlHyO8ehzM+Ql5qgDgPFwXZM4IRl/3cqq32gnpBN49+0Tqi Fiew== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h8-v6si9223205pli.14.2018.09.14.15.24.32; Fri, 14 Sep 2018 15:25:31 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727941AbeIODkE (ORCPT + 99 others); Fri, 14 Sep 2018 23:40:04 -0400 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:42234 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726969AbeIODkE (ORCPT ); Fri, 14 Sep 2018 23:40:04 -0400 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail06.adl2.internode.on.net with ESMTP; 15 Sep 2018 07:53:37 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1g0wUy-0008D2-G2; Sat, 15 Sep 2018 08:23:36 +1000 Date: Sat, 15 Sep 2018 08:23:36 +1000 From: Dave Chinner To: =?utf-8?B?54Sm5pmT5Yas?= Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca, linux-kernel@vger.kernel.org Subject: Re: metadata operation reordering regards to crash Message-ID: <20180914222336.GD16550@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 14, 2018 at 05:06:44PM +0800, 焦晓冬 wrote: > 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 still > the original file(or not exists)? Not for XFS, ext4, btrfs or f2fs. Other filesystems might be different. Cheers, Dave, -- Dave Chinner david@fromorbit.com