From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valerie Aurora Subject: Re: Fallthrus as full-length symlinks? Date: Tue, 24 Nov 2009 21:15:09 -0500 Message-ID: <20091125021509.GF21724@shell> References: <20091113174631.GD19656@shell> <30797.1258523235@jrobl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, David Woodhouse , Alexander Viro , Jan Blunck , Christoph Hellwig , Andy Whitcroft , Scott James Remnant , Sandu Popa Marius , Jan Rekorajski , Arnd Bergmann , Vladimir Dronnikov , Felix Fietkau To: hooanon05@yahoo.co.jp Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758230AbZKYCP2 (ORCPT ); Tue, 24 Nov 2009 21:15:28 -0500 Content-Disposition: inline In-Reply-To: <30797.1258523235@jrobl> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Nov 18, 2009 at 02:47:15PM +0900, hooanon05@yahoo.co.jp wrote: > > Valerie Aurora: > > Fallthrus were invented as a placeholders for readdir() on a > > union-mounted directory - basically, to use the top-level file > > system's readdir() cookie mechanism. Fallthrus are persistent > > directory entries and are implemented by the underlying file system - > > such as ext2 or tmpfs - in whatever way it sees fit. We've > > implemented them for ext2 in two ways: as a regular directory entry > > with a magic inode number, and as a regular directory entry with a > > special file type. > > > > Recently, David Woodhouse suggested implementing fallthrus as > > full-length symlinks with a special flag. The interesting thing about > > this idea is that it could theoretically let us rename a file from the > > low level file system to another place in the low-level file system > > without copying the contents of the file up. Basically, we can > > arbitrarily swizzle the namespace of the low-level by maintaining a > > set of symlinks above. > > > > Is this useful? Is it implementable? > > I think the idea of fallthru entry is good, even if it is implemented as > a special symlink. > How do you think about the file paths in /proc/pid/maps and > /proc/pid/fd? > They refer the file paths, and some apps depend upon these path. I > remember that the package manager in debian didn't work when the path is > wrong. (But I don't know whether it is true still). > > Will FS have to support such case? My current thinking is that an overlay shouldn't be mounted over /proc or other special file systems. I think that a writable layer should only be mounted over exactly one file system, no submounts allowed. -VAL