[lkml]   [2005]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: reiser4 plugins
    Hans Reiser wrote:
    > It was always the expectation that users would want to have one
    > mountpoint with the files having metafiles as files, and another with
    > the same files but strictly posix, and then their apps can use whichever
    > they have the power to understand.

    It was never in the early betas I tried :(

    I'm proposing (or re-proposing) that the /meta mountpoint be strictly
    for accessing meta-files, with no intention of eventually using this by
    default. Furthermore, /meta should follow POSIX anyway, mostly -- no
    file-as-dir there, either, although you still wouldn't want to use tar
    on it.

    With only a few patches, using /meta could be almost as convenient as
    using file/..metas/foo, and it completely kills the file-as-directory
    flamewar -- everybody's happy.

    Or so I thought. It seems that the people arguing for file-as-directory
    are ignoring /meta, and the people arguing against it are arguing
    against all meta-files, saying that the good things about meta-files
    don't justify the risks of file-as-dir. Only once did I see someone
    bring up /meta.

    I don't like the idea of having /meta have file-as-dir and everything as
    we originally wanted, because then we've duplicated the interface. To
    read the *contents* of /foo, I can either cat /foo or cat /meta/foo.
    I'd hate to have the POSIX mountpoint still lying around if no one's
    using it, even more than I hate the idea of "foo" being in two places
    for no good reason.

    Is there a technical (performance?) reason that my approach is wrong?
    (metas go in /meta, files go in /, and everything feels POSIX-y)

    > Hans
    > David Masover wrote:
    >>Hubert Chan wrote:
    >>>On Wed, 29 Jun 2005 17:34:41 -0400, Ross Biro <>
    >>>>I'm confused. Can someone on one of these lists enlighten me?
    >>>>How is directories as files logically any different than putting all
    >>>>data into .data files and making all files directories (yes you would
    >>>>need some sort of special handling for files that were really called
    >>>>.data). Then it's just a matter of deciding what happens when you
    >>>>call open and stat on one of these files?
    >>>Logically, I don't think there is a difference. A filesystem that
    >>>doesn't support file-as-dir could implement the same functionality that
    >>>way. [1] In fact, that's essentially what MacOS X/NeXTSTEP does with
    >>>bundle format -- it's just a regular directory with regular files
    >>I, personally, would hate it if everything in my /bin suddenly became
    >>a directory, mainly because everything would stop working. Is that
    >>the kind of thing you're suggesting?
    >>I'm a little confused about the .data idea, I guess.
    >>>>But we could have a whole new set of system calls that treat things as
    >>>>magic, and if files as directories is as cool as many people think,
    >>>>apps will start using the new api. If not, they won't and the new api
    >>>>can be deprecated.
    >>>File-as-dir doesn't require new system calls (that I know of), which is
    >>>the whole point of the idea. Existing programs can edit the strange new
    >>>attributes without being modified.
    >>That is indeed the point, but scroll down.
    >>>The main thing blocking file-as-dir is that there are some
    >>>locking(IIRC?) issues. And, of course, some people wouldn't want it to
    >>>be merged into the mainline kernel. (Of course, the latter doesn't
    >>>prevent Namesys from maintaining their own patches for people to play
    >>>around with.)
    >>What's the locking issue? I think that was more about transactions...
    >>>People like Horst (and probably others, who are less vocal), I think,
    >>>don't think that it's even worth trying it out because they don't see
    >>>any major advantages. Or at least they think that the potential
    >>>negatives outweigh the potential positives. I respect that they have
    >>>different opinions, but I of course disagree and attempt to convince
    >>>them otherwise.
    >>Did the /meta (metafs) idea get killed while I was out? Using that
    >>approach, your potential negatives are that apps which crawl the
    >>entire FS tree, starting at /, with hardcoded apps for /proc and /sys,
    >>are now broken -- but then, /sys already broke them once, so I don't
    >>particularly care if we break them again.
    >>Potential positives? I think even just because we like the idea is
    >>enough, because it doesn't break anything and doesn't really affect
    >>anyone who doesn't use it.
    >>Maybe there are coding standards, but I think others are working that
    >>out now.

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

     \ /
      Last update: 2005-07-01 10:30    [W:0.030 / U:16.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site