From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FA93303C88 for ; Fri, 24 Oct 2025 13:34:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761312849; cv=none; b=h3h8IggOed9P0k4tEtVsM2XArMprGbt0gFC/q+O1WZoDhc5zggtFSSIhRKa66I1B9doqsGnMd0xCaP2uNB6t+Lu8VVWCQUPqMjMZ8uAC8JECYQZh5l3HQqNIM1/tuUBfPiHVvFXfl3yg17XSkel/yoj7UC90MMbZUnL+zmev9as= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761312849; c=relaxed/simple; bh=rNe/wMVh+r43gOdK8YRpl2xWvTEexBZFYxKyF8+XnCg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bCN0/8qu7jXwWqxIA3NG3fkTPZSVgAQV0yVR52ROt7jv8gWhOHjp0ZNnpkApzeqZSmBLdzh7bDuWEaD5dwjQtUrTF+d1KvzvQ5q8mCpqO7xWo+ykKND8Rnndl7jxfgAAF19qawbldCttpBHDTOM/acrlty1pdpcQt6mOhT0IQ4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=bur.io; spf=pass smtp.mailfrom=bur.io; dkim=pass (2048-bit key) header.d=bur.io header.i=@bur.io header.b=DzQIOBdd; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=mEwksrwi; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=bur.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bur.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bur.io header.i=@bur.io header.b="DzQIOBdd"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="mEwksrwi" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9EBA114001E1; Fri, 24 Oct 2025 09:34:04 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Fri, 24 Oct 2025 09:34:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1761312844; x=1761399244; bh=JUoF31XGhe GVPhu6yNPHfmcQ/jqLec9tHuNWP/DAcsE=; b=DzQIOBdd6YUpJC6qODYlCPj65i a6yM07qRdtoodU5rIkPelVlI+ZmvkE5FOm1ownASnjVu5pkbVkYFuryeqKfTG0fE ISrLM0R2rGfgqr1nBhl0QMrW7lvfIFne5Z6DE5WLkWy1v04sQocHAWH5FvRgw6BP 3FuGy08hR9yUhNGn19elayMvsqRP+lqa7sACvWbpIqWrXdwM8IyXX1SyslLYwLIC Tv7v7RyLBBDpMpexWBZquFMO8EdefRLMOqhuQT+7GEhi8aeBMavp7MuNCexNc3wN LpPdXPjXI7NYU2NnZoSL/QnzKAROxpNuMDkCCB3ESZJgv9gYn/G2MkKCjq5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1761312844; x=1761399244; bh=JUoF31XGheGVPhu6yNPHfmcQ/jqLec9tHuN WP/DAcsE=; b=mEwksrwiJRukr46t7a0Y3eGJiuIM6G9eEneHA3PdXZUPnOY02Wj ESE8hrujVIqf087nPUoaXmTGdalPQf4VBg9Uzi2RIgk4QFJxuSZKAz9JlVyK9ORi vEC/OHQU+r0k23FUK5z50HO3kukI2QjLXH9wKx1zeH/Ckt1hqmAgTZgaUbA8LVin tzdfhHdT+eZFijX5BCD8B0S6FjO2mOe2awFtTsb3V3MkBH0C4uTdmBhi8KuV/S2x sFUvULOb36Oa1/1VwgJYV6zntNT1j/kGaPXnxp3ivNMPEfVEOb7sZ4Dkg0uRFlET RxnpstlbOvBwajYUZ1Qpn1F13VY5w6i63uA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddugeelgeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpeeuohhrihhsuceuuhhrkhhovhcuoegsohhrihhssegsuhhrrdhi oheqnecuggftrfgrthhtvghrnhephedthfevgffhtdevgffhlefhgfeuueegtdevudeihe eiheetleeghedvfeegfeegnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhrihhssegsuh hrrdhiohdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthht ohepfhgumhgrnhgrnhgrsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqd gsthhrfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Oct 2025 09:34:04 -0400 (EDT) Date: Fri, 24 Oct 2025 06:34:01 -0700 From: Boris Burkov To: fdmanana@kernel.org Cc: linux-btrfs@vger.kernel.org Subject: Re: [PATCH] btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name Message-ID: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Oct 24, 2025 at 12:52:02PM +0100, fdmanana@kernel.org wrote: > From: Filipe Manana > > If we are logging a new name make sure our inode has the runtime flag > BTRFS_INODE_COPY_EVERYTHING set so that at btrfs_log_inode() we will find > new inode refs/extrefs in the subvolume tree and copy them into the log > tree. > > We are currently doing it when adding a new link but we are missing it > when renaming. > > An example where this makes a new name not persisted: > > 1) create symlink with name foo in directory A > 2) fsync directory A, which persists the symlink > 3) rename the symlink from foo to bar > 4) fsync directory A to persist the new symlink name > > Step 4 isn't working correctly as it's not logging the new name and also > leaving the old inode ref in the log tree, so after a power failure the > symlink still has the old name of "foo". This is because when we first > fsync directoy A we log the symlink's inode (as it's a new entry) and at > btrfs_log_inode() we set the log mode to LOG_INODE_ALL and then because > we are using that mode and the inode has the runtime flag > BTRFS_INODE_NEEDS_FULL_SYNC set, we clear that flag as well as the flag > BTRFS_INODE_COPY_EVERYTHING. That means the next time we log the inode, > during the rename through the call to btrfs_log_new_name() (calling > btrfs_log_inode_parent() and then btrfs_log_inode()), we will not search > the subvolume tree for new refs/extrefs and jump directory to the > 'log_extents' label. > > Fix this by making sure we set BTRFS_INODE_COPY_EVERYTHING on an inode > when we are about to log a new name. A test case for fstests will follow > soon. > > Reported-by: Vyacheslav Kovalevsky > Link: https://lore.kernel.org/linux-btrfs/ac949c74-90c2-4b9a-b7fd-1ffc5c3175c7@gmail.com/ > Signed-off-by: Filipe Manana Reviewed-by: Boris Burkov > --- > fs/btrfs/inode.c | 1 - > fs/btrfs/tree-log.c | 3 +++ > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 79732756b87f..03e9c3ac20ed 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -6885,7 +6885,6 @@ static int btrfs_link(struct dentry *old_dentry, struct inode *dir, > BTRFS_I(inode)->dir_index = 0ULL; > inode_inc_iversion(inode); > inode_set_ctime_current(inode); > - set_bit(BTRFS_INODE_COPY_EVERYTHING, &BTRFS_I(inode)->runtime_flags); > > ret = btrfs_add_link(trans, BTRFS_I(dir), BTRFS_I(inode), > &fname.disk_name, 1, index); > diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c > index 65079eb651da..8dfd504b37ae 100644 > --- a/fs/btrfs/tree-log.c > +++ b/fs/btrfs/tree-log.c > @@ -7905,6 +7905,9 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans, > bool log_pinned = false; > int ret; > > + /* The inode has a new name (ref/extref), so make sure we log it. */ > + set_bit(BTRFS_INODE_COPY_EVERYTHING, &inode->runtime_flags); > + > btrfs_init_log_ctx(&ctx, inode); > ctx.logging_new_name = true; > > -- > 2.47.2 >