Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764815AbXEWKPX (ORCPT ); Wed, 23 May 2007 06:15:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757237AbXEWKPL (ORCPT ); Wed, 23 May 2007 06:15:11 -0400 Received: from mail-gw3.sa.ew.hu ([212.108.200.82]:58395 "EHLO mail-gw3.sa.ew.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756828AbXEWKPK (ORCPT ); Wed, 23 May 2007 06:15:10 -0400 To: viro@ftp.linux.org.uk CC: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, torvalds@linux-foundation.org In-reply-to: <20070523095824.GR4095@ftp.linux.org.uk> (message from Al Viro on Wed, 23 May 2007 10:58:24 +0100) Subject: Re: [RFC PATCH] file as directory References: <20070522221045.GH4095@ftp.linux.org.uk> <20070523070306.GM4095@ftp.linux.org.uk> <20070523073658.GO4095@ftp.linux.org.uk> <20070523082918.GP4095@ftp.linux.org.uk> <20070523095824.GR4095@ftp.linux.org.uk> Message-Id: From: Miklos Szeredi Date: Wed, 23 May 2007 12:14:28 +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1584 Lines: 35 > On Wed, May 23, 2007 at 11:03:08AM +0200, Miklos Szeredi wrote: > > I still don't get it where the superblock comes in. The locking is > > "interesting" in there, yes. And I haven't completely convinced > > myself it's right, let alone something that won't easily be screwed up > > in the future. So there's definitely room for thought there. > > > > But how does it matter if two different paths have the same sb or a > > different sb mounted over them? > > Because then you get a slew of fun issues with dropping the final reference > to vfsmount vs. lookup on another place. What hold do you have on that > superblock and when do you switch from "oh, called ->enter() on the same > inode again, return vfsmount over the same superblock" to "need to > initialize that damn superblock, all mounts are gone"? > > > The same dentry is mounted over each one. The contents of the > > directory should only depend on the contents of the underlying inode. > > The path leading up to it is completely irrelevant. > > So what kind of exclusion do you have for ->enter()? None? > So really these issues, are about how do we get hold of the superblock to mount. I think that should be a filesystem internal problem, and I suspect the easiest solution is to just have a permanent meta superblock for these dir-on-file mounts. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/