From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96CE537F732 for ; Thu, 15 Jan 2026 15:43:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768491786; cv=none; b=ocm5BDZQBjgS03U/tdilZyd7h7i6dr67c/0NGTa7+AfO2i1s9DYu47vsF6Ie/At2Ak5ISkwC0ASvW5e2FS+INQMqowdqz4ACPpKnk7Kgk/vJNCNBAcQwtFUXE8znBRuEp1DU3Z8NziHi6acEM/rPPp/tq7pcvWWEwDBdKdoOHfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768491786; c=relaxed/simple; bh=0vKTsUqOaThK+m6hWl1cnCBP4ap6ZiOFtdIs3WfFwW0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mNC5A6uL1YO+nSQ8na9MEltf4R83TaTbzFhP83vSCCp9Y7/xkIo2yoB/5v6FvWZ3pCF0TKPu2suWUiERXIaQ+s6orrokLDpmq6kiMMGndvsYiTw2PwF2yGicDmblh9wL+kgGKI7T5nu+j6su4oqX2tN7/wxp/Ni0R69NS28krZ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VVlJ3/rU; arc=none smtp.client-ip=209.85.208.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VVlJ3/rU" Received: by mail-ed1-f68.google.com with SMTP id 4fb4d7f45d1cf-653781de668so1554734a12.2 for ; Thu, 15 Jan 2026 07:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768491783; x=1769096583; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=r3zXNTV1asu+2nK1dsZ2LdKYvZ1vcDLkY/oeQfy1v7E=; b=VVlJ3/rUUYheYBxSGpL2Wt40u84TB/G9q94hhi2ZFfaFSNxh27xU1Z7zPkjnChh3+j vUiNGJNxPUQpocLt7ztEI2A7ohhkcQ1EpvibrGao/GW6s26rV1MK3gowvVAV+wTkMoh3 qT1ClQfrOGC1LLyMKBNY40hvRbrDQdvDJ0pTjj/A2hovzUFr9/itWbzWQcLoascUDE07 pxe7aVYP0IBy0xDYI0WIKCogzCon8C93OcWTavwtDU7P4vLSAz4D0XFTQq1y73KrXZkE RdM1HTKnuUNJ8X9Cr/DWmV7hQq3R7S3UI56t048c67BuXyEq3PgWztcD8M+l2TVHWmgh wTWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768491783; x=1769096583; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r3zXNTV1asu+2nK1dsZ2LdKYvZ1vcDLkY/oeQfy1v7E=; b=KhFedhixReQ0mOQm7GULxd/SJgeJ3u3uoSxyUY6nEk5zXJbdiSmg1+uZdHtBvXod4d X0rfXKwztpfqBf9RIvAy59X7XLF5dtVxzix/kQwGw8A4Xn3sZRQLFV4NzTGfOko0/+a8 +CLERIlVempUgmAftVOiwBlxJIjgyLMJzSGvzHbplZ+1nqF3CJQPGOZ4kcNP3KiBX9JE pP1tHnD8lj0PJT0uAQUxChNdIu8RB4Y1yr4vGrQdeYN+lrEbNow5yXCZpTlVDX9BeTos 6SdAty+76N4B6zHJNRaanJCpC33+fr6c3BcJ5PVJH0VQf7kJfgQkNoHX2uL7aiFX3LRK evkA== X-Forwarded-Encrypted: i=1; AJvYcCXth2qx5Iw8r7/d5AAQZdTtb3XoSijstbuyll5oJCHBZiirJ7SI6BBOdIBU/WOUnucWj3uksAf6f+NsATo=@vger.kernel.org X-Gm-Message-State: AOJu0YwWHlwV1RdIdQNOHqAFvWloHPjKss6eNiafjv8WB6HcSJa5YelN bb5D6hobHXqWzBNcaslCfuTRgbKwsCPH45Pwyc0Wqxb1mzOfxB7iL+T8 X-Gm-Gg: AY/fxX52JcgoYz1bB9PU3pMWMFEVFrunc+jqSb/87SmaSoIOnyFAb0/5hfeTM5T7I3w Lo+zjB5T3huC10nXKoJbUUjo3hticLm/TJW6wfpjl6X9iLnKpodSbYkqNhTDD2XhtKUR8TbQiDS /o0v+U0DZbjIOq0qndl76f9CPPS1Fyz4rUbcbIJxSFosEfD7of9to82OU9pNripyxczHuFz0G/q a65xDDRcSfVhyRluXD4P0+DuawuhTx6UFOVEpmO4NGqU5WGFXvbGe8UtXthhFNydjbwAbmKvKWl q9vDcbUrZmnAtlAU9x75ux/ekhlxkP4bE+YKZOx+vw/ueogDbBYF/aDojAVmW17Q1YxuBhq9kkX svlq+8vRjf+n+KrRrOqM5L0lyOp+nHP472om6znFXPCUHU7AP9UBe55ezRg15ybRRp6RhAR+pa+ PJBm6wjrgqgV+3k/TnuvWXZ17b6vuCXBTurQvXZ9UWeON1b13F3TvuC3UT2O5PpmxzAyahvqDMW 43yjTavZ4PfvgalVnuiJtQJSvc= X-Received: by 2002:a05:6402:44c7:b0:64b:4540:6edb with SMTP id 4fb4d7f45d1cf-653ee1a7c7cmr3799746a12.22.1768491782605; Thu, 15 Jan 2026 07:43:02 -0800 (PST) Received: from localhost (2001-1c00-570d-ee00-7a88-ab31-60c0-33c9.cable.dynamic.v6.ziggo.nl. [2001:1c00:570d:ee00:7a88:ab31:60c0:33c9]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65412084048sm2860511a12.26.2026.01.15.07.43.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 07:43:01 -0800 (PST) Date: Thu, 15 Jan 2026 16:43:01 +0100 From: Amir Goldstein To: Chunsheng Luo Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 0/2] fuse/passthrough: simplify daemon crash recovery Message-ID: References: <20260115072032.402-1-luochunsheng@ustc.edu> Precedence: bulk X-Mailing-List: linux-kernel@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: <20260115072032.402-1-luochunsheng@ustc.edu> On Thu, Jan 15, 2026 at 03:20:29PM +0800, Chunsheng Luo wrote: > To simplify FUSE daemon crash recovery and reduce performance overhead, > passthrough backing_id information is not persisted. However, this > approach introduces two challenges after daemon restart: > > 1. Non-persistent backing_ids prevent proper resource cleanup, leading > to resource leaks. > 2. New backing_ids allocated for the same FUSE file cause -EIO errors > due to strict fuse_backing validation in > fuse_inode_uncached_io_start(), even when accessing the same > backing file. This persists until all previously opened files are > closed. > > There are common scenarios where reusing the cached fuse_inode->fb is > safe: > > Scenario 1: The same backing file (with identical inode) is > re-registered after recovery. > Scenario 2: In a read-only FUSE filesystem, the backing file may be > cleaned up and re-downloaded (resulting in a different > inode, but identical content). That is just not acceptable by design, regardless of server restart. fuse passthrough may be configured per individual file open, but all fd referring to the same fuse inode need to passthrough to the same backing inode. If your server want to serve different fd of same fuse inode from different backing files (no matter if they claim to have the same content), server needs to do that with FOPEN_DIRECT_IO, it cannot do that with FOPEN_PASSTHROUGH. Thanks, Amir. > > Proposed Solution: > > 1. Enhance fuse_dev_ioctl_backing_close() to support closing all > backing_ids at once, enabling comprehensive resource cleanup after > restart. > > 2. Introduce the FOPEN_PASSTHROUGH_INODE_CACHE flag. When set during > fuse_open(), the kernel prioritizes reusing the existing > fuse_backing cached in fuse_inode, falling back to the > backing_id-associated fb only if the cache is empty. > > I'd appreciate any feedback on whether there are better approaches or > potential improvements to this solution. > > Thanks. > --- > Chunsheng Luo (2): > fuse: add close all in passthrough backing close for crash recovery > fuse: Add new flag to reuse the backing file of fuse_inode > > fs/fuse/backing.c | 14 ++++++++++++++ > fs/fuse/dev.c | 5 +++++ > fs/fuse/fuse_i.h | 1 + > fs/fuse/iomode.c | 2 +- > fs/fuse/passthrough.c | 11 +++++++++++ > include/uapi/linux/fuse.h | 2 ++ > 6 files changed, 34 insertions(+), 1 deletion(-) > > -- > 2.43.0 >