lkml.org 
[lkml]   [2004]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: silent semantic changes with reiser4
    On Thu, Aug 26, 2004 at 01:11:52AM +0100, Jamie Lokier wrote:
    > Is this a problem if we treat entering a file-as-directory as crossing
    > a mount point (i.e. like auto-mounting)?

    Yes - mountpoints can't be e.g. unlinked. Moreover, having directory
    mounted on non-directory is also an interesting situation.

    > Simply doing a path walk would lock the file and then cross the mount
    > point to a directory.

    *Ugh*

    What would happen if you open that directory or chdir there? If it's
    "underlying file stays locked" - we are in even more obvious deadlocks.

    > A way to ensure that preserves the lock order is to require that the
    > metadata is in a different filesystem to its file (i.e. not crossing a
    > bind mount to the same filesystem).
    >
    > That has the side effect of preventing hard links between metadata
    > files and non-metadata, which in my opinion is fine.

    We don't actually need a different fs - different vfsmount will do just fine.

    > The strict order is ensured by preventing bind mounts which create a
    > path cycle containing a file->metadata edge. One way to ensure that
    > is to prevent mounts on the metadata filesystems, but the rule doesn't
    > have to be that strict. This condition only needs to be checked in
    > the mount() syscall.

    You really don't want to lock mountpoint on path lookup, so I don't see
    how that would be relevant - it's a hell to clean up, for one thing
    (I've crossed ten mountpoints on the way, when do I unlock them and
    how do I prevent deadlocks from that?) Besides, different namespaces
    can have completely different mount trees, so tracking down all that
    stuff would be hell in its own right.

    The main issue I see with all schemes in that direction (and something
    like that could be made workable) is the semantics of unlink() on
    mountpoints. *Especially* with users being able to see attributes of
    files they do not own (e.g. reiser4 mode/uid/gid stuff). Ability to
    pin down any damn file on the system and make it impossible to replace
    is not something you want to give to any user.
    -
    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:05    [W:4.648 / U:0.616 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site