From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a6-smtp.messagingengine.com (fout-a6-smtp.messagingengine.com [103.168.172.149]) (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 506233AC0F8; Wed, 8 Jul 2026 20:18:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.149 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783541939; cv=none; b=Jsi7au5/Pgc1a4pg+B6VuFmCy5Do7O7r6dzZPvWSc4pCJOtPUHyHe1Kr79JiJOdjz6y/yibcsMVBdbyPM4zla919wQhTACXYfBe8FDJSYxXNPrpuebp0Cs9Jvz984ONeU1ua2uAUTxxETS0/FculcmjMynmSacU1F3xe8OHYfdc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783541939; c=relaxed/simple; bh=wLGhsWeNJi8zd8/PkkwZnzKfSNF/g1DdrFV0OOf9YqY=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=cd4pXA42AZsu2c9W/VFHEWBTMvZhq2JATQ8SfChMlQqxFxJfESXJMurST2gXDH6y9itSe2cVvR1uhxRmXP9jnxI6hppEgHcA1YD7zh78j4BS4LvE80TUTbryNo2ZYcJD7hVeVGqTi55Polad2m+NRGtg6pFXMyaYMsn6IEB7+C0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=verbum.org; spf=pass smtp.mailfrom=verbum.org; dkim=pass (2048-bit key) header.d=verbum.org header.i=@verbum.org header.b=ow/n4Rit; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=izvy4diN; arc=none smtp.client-ip=103.168.172.149 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=verbum.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=verbum.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=verbum.org header.i=@verbum.org header.b="ow/n4Rit"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="izvy4diN" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 8D654EC0088; Wed, 8 Jul 2026 16:18:54 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-04.internal (MEProxy); Wed, 08 Jul 2026 16:18:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verbum.org; h=cc :cc:content-transfer-encoding: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=fm2; t=1783541934; x=1783628334; bh=wLGhsWeNJi8zd8/PkkwZnzKfSNF/g1DdrFV0OOf9YqY=; b= ow/n4Rit5tUlEd2H3q0EG/TVdn2dzyC9g40PZAHxVjO+WA2ydZCUqPcuwfiQpSYA hhKT1Noiibx3cz96xPjI2Y27BGua9XfG0ZR6DKwsEdyyB8kus0twp75/VTK3+R2I 8vkeWggo1FepJd//zs5uAQZftRuqS6so3/5TyP1yi6EMi5tFXFiuYbe4l41hoQbn pEhGkSEO4ogzNbO6mcyAbhhDXzfEtR4fxb1LvDGtkTyZfRMKrjtOOosWK84zN3uj mPzwVbTkSUp/dTR1Hmm6VXQc7i4iRkULOID8fp4QevA/ZmbfqOEZzHnjB6hjujhx pyJlW6/I93gxiD5UJqOpEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=1783541934; x= 1783628334; bh=wLGhsWeNJi8zd8/PkkwZnzKfSNF/g1DdrFV0OOf9YqY=; b=i zvy4diNMr3EwaUdCBT9je5mqS3VjvyctlwpE65BoychvpB3oJDOS5DUOtLm6wG3l 3g0Bvc1TjviPgXe0SikEnvSTcda8J+cc6iu6Xo/B4rpqvO+Vq2YISWAigBkRwfGf GzML+QhW+smpde/ZmnIV10Hl+vV3N/JVnI8qspZx/OqsSWXeas7KrdsFkTvKtH2Q UMW8cVGk5Lq0Jogxvmve/FtUk0C9cPPQfI4JIasJOSRax1ZAJnlUfhEWwzsVS9Kk qyyyDyEvg12ZytxZ8bTaTX5vwgJAp3+tUUJjU0hb8IKADFbk17h6+Y814M15kMtH 6LhjgcDqntOkjdGO8tJzw== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFeSPUT25v+12YVMbRBoofLsuPVc5lWVwFljbzt+zLqPXzvS4js3nW+jwmR6qiqwK l2E1L2sYGTAVEOpkxbHitkR4MrfePAFXCI95P8r5vW1cHnVPCapFoN0ksFkpcPxyOHmjxl Q3UxS3CfKznUJH9t1bb7dweAudc2NLBNNlY1Vj7KPNO2ClMqoqCcuR3Q4xEz1xXArAzlop kwDj1fHHL+1dmUAm7uAufaAoVr+O5SZtsPm2xR/ajf376wN043bEH0kqXoeeZ59scvJ8z9 76XrIh3FM51EuTUDOesyqUyUYoIgl9o4yEE737hNR5K56mapr0aGMZ91aUILk06vtrnEbM 0RztINzHEmPpqgUYqcS9DOomOKoubBzWKw/Tej5NK3ZRw+/Qxay/KC7Cim4YeHAIyeHYeo SojHnAD4pd0S7zm8czFFehVDgwXBww4HO3xJG/ByIkffHDjU/4QyVXLtf4jtnXgds6VAt0 4cGcs4eHp4pB2lmSOaLKZJSLbZ7ehGHkdn4ZDvCrWghr0mc3VMmVPvaDnE8BRkBnppoF1Y ozs/0cHxXxVYFDU4/2Cf7Nx7NVCy5bIa+UnjdiAHpQtX1Qy8tUmwmjTxt6/KNlEqVweqYA aOcuqZsXiJCWmCSTvM+M0nMkPVB/LxltxZr1fjRDzZxKW5GmcgLA9ztdInPQ X-ME-Proxy: Feedback-ID: ibe7c40e9:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id B2F56780AB5; Wed, 8 Jul 2026 16:18:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AP2jg_FR6fcw Date: Wed, 08 Jul 2026 16:16:42 -0400 From: "Colin Walters" To: "Amir Goldstein" , "Giuseppe Scrivano" Cc: "Miklos Szeredi" , "linux-unionfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , linux-api@vger.kernel.org, "Al Viro" , "Christian Brauner" , "Gao Xiang" , "linux-erofs mailing list" Message-Id: <01df945c-9dbc-4b80-b71c-f68aa70fb8bf@app.fastmail.com> In-Reply-To: References: <20260708095831.3381978-1-gscrivan@redhat.com> <878q7l8y4y.fsf@redhat.com> <87wlv57dt1.fsf@redhat.com> <87o6gh79yi.fsf@redhat.com> Subject: Re: [PATCH] ovl: add ioctls to retrieve layer file descriptors Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 8, 2026, at 3:01 PM, Amir Goldstein wrote: > If you want to keep a pool of mounted erofs images, you could do that > in userspace - > create a service that indexes mounted erofs images by unique mount poi= nt paths. You're right that it=E2=80=99d be possible to do this in user space.=20 However, overlayfs is used by many things (it=E2=80=99s a powerful =E2=80= =9CSwiss army knife=E2=80=9D!) and this ability to reliably introspect i= ts components is I think generally useful. For example: https://github.com/systemd/systemd/issues/35017#issuecommen= t-2457333218 Various tools want to know the backing filesystem(s) and/or block device= s thereof, and if we don=E2=80=99t have something like this in the gener= al case every overlayfs user would need to agree on a scheme to store th= is data out of band - and manage its lifecycle as mounts change and deal= with where that data is stored with respect to mount namespaces etc. Even if we had this API, would it be better to have a user space cache s= erver for the original use case here? Maybe. I could personally go eithe= r way. But the introspection I think really would be generally useful and there= are code bases (in systemd and in composefs at least) that would start = using it (with fallback for old kernels) for at least that use case righ= t away.