lkml.org 
[lkml]   [2004]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: silent semantic changes with reiser4
    From
    Date
    David Masover <ninja@slaphack.com> writes:

    > |>Second, there are quite a few things which I might want to do, which can
    > |>be done with this interface and without patching programs,
    > | Such as?
    > They've been mentioned.

    > | Haven't seen any that made sense to me, sorry.
    > Sorry if they don't make sense to you, but I don't feel like discussing
    > them now. Either you get it or you don't, either you agree or you
    > don't. Read the archives.

    Great argument. Not. There has been so much shit thrown around here
    so that it's impossible to keep track of all examples.

    Could you please try summarize a few of the arguments that you find
    especially compelling? This thread has gotten very confused since
    there are a bunch of different subjects all being intermixed here.

    What are we discussing?

    1. Do we want support for named streams?

    I belive the answer is yes, since both NTFS and HFS (that's the
    MacOS filesystem, isn't it?) supports streams we want Linux to
    support this if possible.

    Anyone disagreeing?

    2. How do we want to expose named streams?

    One suggestion is file-as-directory in some form.

    Another suggestion made is to expose named streams somewhere under
    /proc/self/fd.

    Yet another suggestion is to use the openat(3) API from solaris.

    Some filesystems exposes extra data in a special directory in the
    same directory as the file, such as netapps .snapshot directories
    or the extra directories that netatalk expects. This has the
    advantage that it even works on non-named stream capable
    filesystems, but it has a lot of problems too.

    Linux already has limited support for names streams via the xattr
    interface, but it's not a good interface for people wanting to
    have large files as named streams.

    4. What belongs in the generic VFS, what belongs in Reiser4?

    Some things reiser4 do, such as files-as-directories need changes
    to the VFS because it breaks assumptions that the VFS makes
    (i.e. a deadlock or an oops when doing a hard link out of one).

    Some other things reiser4 can do would be better if they were in
    the VFS since other filesystems might want to support the same
    functionality.

    Or Linux may not support some of the things reiserfs at all.

    5. What belongs in the kernel, what belongs in userspace?

    This is mostly what I have been trying to argue about.

    So, to try to summarize my opinion, regarding file-as-directory, I
    belive it's fatally flawed because it breaks a lot of assumptions that
    existing code make. One example of an application that will break is
    a web server that tries to filter out accesses to "bad" files,
    files-as-directories suddenly means that part of those files will be
    accessible (and there are a _lot_ of CERT reports on just this kind of
    problems with Windows web servers due to access to named streams not
    being restricted or ways to access files with non-canonical names that
    also managed to bypass access restrictions).

    Files-as-directories also does not give us named streams on
    directories. The suggestion to have dir/metas access the named
    streams means that if someone already has a file named metas in a
    directory that file will be lost. (Does anyone remember the
    discussions about the linux kernel having a directory named "core" and
    the problems this caused for some people?)

    All this suggests to me that named streams must live in another
    namespace than the normal one. To me, openat(3) seems like a good
    choice for an API and it has the advantage that someone else, Solaris,
    already has implemented it.

    Additionally, files-as-directores does not solve the problem of
    "cp a b" losing named streams. There is curently no copyfile syscall
    in the Linux kernel, "cp a b" essentially does "cat a >b". So unless
    cp is modified we don't gain anything. If cp is modified to know
    about named streams, it really does not matter if named streams are
    accessed as file-as-directories, via openat(3) or via a shared library
    with some other interface.

    Regarding the kernel or userspace discussion. In my opinion anything
    that can be done in user space should be done in userspace. If the
    performance sucks, or it has security problems, or needs caching that
    cant be solved in userspace it can be moved to the kernel, but in that
    case the smallest and cleanest API possible should be implemented.

    If, for historical reasons, an API must be in the kernel, there is not
    much we can do about it either. It'll have to stay there, but we can
    avoid making the same mistakes again.

    So, for all the examples of the kernel having plugins that
    automatically lets an application see a tar-file as a directory, I
    really, really don't belive this belongs in the kernel. First of all,
    this is the file-as-directory discussion again, I belive it is a
    mistake to expose the contents as a directory on top of the file
    because it breaks a lot of assumptions that unix programs make.

    It's much better to expose the contents at another place in the
    filesystem by doing a temporary mount of the file with the proper
    filesystem. As Pavel Machek pointed out, this has the problem of who
    cleans up the mount if the application crashes. One way to handle
    this could be something like this:

    mount -t tarfs -o loop bar.tar /tmp/bar-fabb50509
    chdir /tmp/bar-fabb50509
    umount -f /tmp/bar-fabb50509

    This will require the ability to unmount busy filesystems (but I
    belive Alexander Viro already has implemented the infrastructure
    needed for this).

    Or for files that we don't have a real filesystem driver (or on other
    systems where userspace mounts are not allowed), we could just unpack
    the contents into /tmp. For cleanup we could let whatever cleans up
    /tmp anyways handle it, or have a cache daemon that keeps track of
    untarred directories and removes them after a while.

    Another way is to completely forget about presenting the contents of a
    tar file as a real files, and just use a shared library to get at the
    contents (now we just have to convince everyone to use the shared
    library). This would also be portable to other systems.

    If we do this right, it could all be hidden in a shared library, and
    if the system below it supports more advanced features, it can use it.

    Regarding the "I want a realtime index of all files". I belive that a
    notifier that can tell me when a file has been changed and a userspace
    daemon ought to handle most of the cases that have been mentioned.
    The suggested problems of not getting an up to date query response can
    be handled by just asking the daemon "are you done with indexing yet".
    The design of such a daemon and the support it needs from the kernel
    can definitely be discussed. But to put the indexer itself in the
    kernel sounds like a bad idea. Even adding an API to query the
    indexer into the kernel sounds pointless, why do that instead of just
    opening a Unix socket to the indexer and asking it directly?

    /Christer

    --
    "Just how much can I get away with and still go to heaven?"

    Freelance consultant specializing in device driver programming for Linux
    Christer Weinigel <christer@weinigel.se> http://www.weinigel.se
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:0.046 / U:30.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site