[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (Semi-random) thoughts on device tree structure and devfs
On Fri, Mar 12, 2010 at 7:34 AM, Greg A. Woods <woods%planix.ca@localhost>
> At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi
> <uebayasi%gmail.com@localhost> 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
> 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
# cat wd0/.info
Main Index |
Thread Index |