On Fri, Mar 12, 2010 at 7:34 AM, Greg A. Woods <wo...@planix.ca> wrote: > At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi <uebay...@gmail.com> > wrote: > Subject: Re: (Semi-random) thoughts on device tree structure and devfs >> I think labels should be resolved by some name service. It's not >> different than /etc/hosts -> IP address. > > Sorry, but I'm flabbergasted! What the heck does that mean in this > context of filesystem identification? > > Do you really want to add more complexity, goo, and mess, and places for > errors to happen by adding a translation layer? > > First off, there's really nowhere to store your magical mappings. > > K.I.S.S. Please! > > We do have a place to store a human readable/meaningful filesystem > identifier. > > Let the human provide this label. > > If the system finds duplicate labels then tell the human which devices > have conflicting labels and where those filesystem were last mounted and > let the human decide which device should be used. (i.e. the labels do > need to be unique for a successful automatic initialisation of the > system, but there needs to be a manual way to work around them not being > unique regardless of what data they consist of) > > In my opinion the fs_id value is truly useless anywhere outside of the > on-disk storage of a single filesystem copy where its sole valid use is > (IIUC) to help to match valid backup superblock copies. The fact I'm > not even sure it's safe or sane to derive the NFS filesystem filehandle > from it in any way.
I want to simplify path namespace. I want labels and other "referencial" informations to be accessed via file, like procfs's doing. # cat wd0/.info Masao