[lkml]   [1998]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Implementing Meta File information in Linux
    You might consider that storing dynamically allocated meta-data is much easier to add to reiserfs (we designed with it as a goal).

    Hans describes reiserfs

    Kenneth Albanowski wrote:

    > On Tue, 25 Aug 1998, Chris Wedgwood wrote:
    > > On Mon, Aug 24, 1998 at 05:30:51PM +0200, Andi Kleen wrote:
    > >
    > > > In article <>,
    > > > "Sebastiano Tine'" <> writes:
    > >
    > > > > I have named it "Meta File Information". They consists in data
    > > > > associated with the single file that user process can set and
    > > > > read.
    > > >
    > > > > Does anyone ever thinked on it or implemented in some way ? I
    > > > > need tips and suggestions on possible implementations.
    > > >
    > > > It is already implemented. It is called a "directory".
    > >
    > > Yup... and IMO its a good way to do it.
    > >
    > > MacOS files can fork into two - but why two? Is two really that
    > > special in this case? And why can't these forks have forks?
    > Last time I was reading through the specs, it appeared that there can be
    > any number of forks, theoretically, in the filesystem. But they cannot
    > nest, and I'd be astonished if the OS actually supported more then two
    > forks per file.
    > > NT has multiple forks, but those forks can't fork, etc.
    > NTFS, you mean. OS/2 (HPFS, but also some hacks to support this on DOSFS)
    > also has forks, to some degree -- its "extended attributes" allow a lot of
    > data to be stored along with a file, though they are more similar to an
    > individual resource file then a set of forks.
    > > I though about this one for a long time once when I was keen on the
    > > metadata idea and decided directories are the most sane way of doing
    > > this. If you want fancy stuff, then make a library that know how to
    > > handle different bits in each directory, etc.
    > Yes, once you go to nesting forks, you might as well call the things
    > directories, and be done with it. (And deal with the efficiency
    > consequences of this -- reiserfs, anyone?)
    > You still are stuck with breaking normal utilities, though, unless you
    > provide some integral way of wrapping the "bundle" up into a flat file, if
    > you try to read directly from the forked "directory". (But even that won't
    > work, as something wanting to read a .c file probably just wants the "data
    > fork", never mind the extra data. You can't win, really, at least not
    > without making "ar", "cp", and "tar" much more special.)
    > > I think NeXT did something like this?
    > To the best of my knowledge, no. They just have a resource format (".nib",
    > I believe) that is easy to work with, much as if a Mac resource fork were
    > stored in a separate file.
    > --
    > Kenneth Albanowski (, CIS: 70705,126)
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.024 / U:14.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site