bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: creation time as Hurd extension?


From: Farid Hajji
Subject: Re: creation time as Hurd extension?
Date: Fri, 18 Jul 2003 14:39:22 +0200 (CEST)

> > Why restricting meta data to a fixed set of attributes?
> > I've read about a (user-)extensible meta-data scheme some
> > years ago in a paper. Unfortunately, I didn't copy that or
> > its reference (arghhh) back then, and I can't find it now :(
> 
> A particular filesystem implementation can have its own extensions and
> its own tools to use these extensions -- except that such extensions
> are not be available via io_stat ().  For instance, ext2 has its own
> attributes that can be managed using lsattr or chattr (under GNU/Linux).

Sure, but that was not what I'm meaning here. Every FS implementation,
including ext2, provides currently a _fixed_ set of attributes/extensions.
This set is generally hard coded in inodes. There is no way for a user
to attach her own set of meta data to the standard set, because the
implementation uses fixed space in the inode (bitmaps etc...) for those
attributes. Even ACLs are currently implemented this way in most FS.

There is no compelling reason to store extensions directly in inodes.
They can be hung off from the inode and stored either in regular or,
shall I say, metadata files (think about it: directories are regular
files too), or in blocks managed by the file system itself. Of course,
the question is how to access these attributes through a special system
call. Things like LDAP come to mind, though they are not necessarily the
only possible solution.

As a quick hack, I could imagine an inode namespace like this:

/fs/.inodes/12343
/fs/.inodes/14232
/fs/.inodes/23232

The meta attributes for inode 12343 in /fs would be stored
in the meta-file /fs/.inodes/12343, e.g. in LDIF format:
  cn: blah blah          # canonical file name
  au: author
  desc: this file is about blah blah
  desc: more desc.
  acl: user-x user-y user-z
  acl: user-a user-b user-c
  acl: user-m user-n user-k

This scheme is extensible, because users are free to add/modify
attributes, just like they would in an LDAP directory. Of course,
not every attribute would be user-accessible/modifiable, so
those meta data files would only be accessed through syscalls
(just like directories in Unix can only be written to by the
FS implementation).

Well, that's just an idea (and not the one in that paper).

> Ludovic.

-- 
Farid Hajji. http://www.farid-hajji.net/address.html 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]