Messages in this thread | | | Date | Thu, 2 Mar 2006 10:36:03 +0000 | From | Al Viro <> | Subject | Re: GFS2 Filesystem [0/16] |
| |
On Thu, Mar 02, 2006 at 10:12:19AM +0000, Steven Whitehouse wrote: > Hi, > > On Tue, Feb 28, 2006 at 12:18:31PM -0500, Phillip Susi wrote: > > I'm a bit confused. Why exactly is this unacceptable, and what exactly > > do you propose instead? Having an entirely separate mount point that is > > sort of parallel to the main one, but with extra metadata exposed? So > > instead of /path/to/foo/.gfs2_admin/metafile you'd prefer having a > > separate mount point like /proc/fs/gfs/path/to/foo/metafile? > > > I believe that is what Christoph is proposing. It does simplify certain > things, not least preventing someone from moving the .gfs2_admin directory > to somewhere other than the root directory of the filesystem or even > removing it completely which would otherwise need to be added as special > cases. > > On the otherhand, its not clear to me at the moment, exactly how to > implement this bearing in mind that both the "normal" filesystem and > the metadata filesystem are really one and the same as far as journaling > and locking are concerned. Perhaps what's needed is one fs with two > different roots. I'm still looking into the best way to do this,
Two superblocks, one keeping a reference to another. Filesystem driver is, of course, the single piece of code, with common locking. There's no need to have the common struct super_block for that and no benefit in doing so - only extra complications. You can easily register two filesystem types in the same driver and have ->get_sb() for your metadata fs parse its arguments in any way it likes. E.g. by doing pathname lookup on what would normally be a device name and seeing if its on a filesystem of the primary type; if it is - grab a reference to struct super_block of that fs and work with it. - 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/
| |