From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Sick VFS question Date: 25 Feb 2003 01:48:39 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id BAA25587 for ; Tue, 25 Feb 2003 01:49:04 -0800 Received: from palladium.transmeta.com (palladium.transmeta.com [10.0.0.117]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id h1P9mfF23088 for ; Tue, 25 Feb 2003 01:48:41 -0800 (PST) Received: (from mail@localhost) by palladium.transmeta.com (8.9.3/8.9.3) id BAA20375 for linux-fsdevel@vger.kernel.org; Tue, 25 Feb 2003 01:48:41 -0800 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi everyone, I'm considering new ideas for autofs v5, and I have a sick question: would the VFS barf completely if autofs would take a dentry belonging to another filesystem and replace the inode pointer with a pointer to an inode belonging to itself (obviously incrementing the counter on that inode appropriately)? This would in particular be applicable to "mount pads", i.e. let's say /auto is an autofs, and /auto/foo is an autofs mount key, containing two filesystems: /auto/foo and /auto/foo/bar. After mounting /auto/foo, autofs would access the "bar" directory in the "foo" filesystem, and replace that inode with an internal autofs inode. This internal inode would have a follow_link(!) method which would cause the /auto/foo/bar mount to happen and then redirect the search to the topmost directory. Ideally, this should not impede a umount of the /auto/foo directory if the /auto/foo/bar directory is not mounted. Using follow_link this way solves a whole lot of problems in autofs, both in terms of usability and atomicity. It solves the same problem the dentry traps was supposed to solve, but also avoids the "mount storm" problem by allowing lstat() without triggering a mount. I would appreciate comments... -hpa -- at work, in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64