0

Of course the system would preventing mounting two things on one directory.

But, what if you mount a FUSE program in the top directory and another FUSE program in a sub directory?

What exactly happens when you call operations on the sub directory?

My assumption is that it initially goes through operations related to mounting from the top FUSE, and then goes to the actual operations you called in the sub FUSE.

Is that correct?

EDIT: Turns out I was wrong about not being able to mount two things in one directory. Then which FUSE program gets priority when two different FUSE programs are mounted on the same directory?

  • Your "edit" is a separate question and should be asked as such (but see also some related questions in the sidebar). – Michael Homer Dec 29 '16 at 0:09
2

Any filesystem can be mounted at any location. All accesses to files inside that mount point are only seen by the mounted filesystem at that location, and not by any surrounding filesystems. This is no different to any other mount you make, which is (necessarily) inside your root filesystem.

As far as the outer filesystem knows, that mount point is just a directory. It wouldn't know what to do with requests for files that aren't inside that directory from its perspective, so your assumption is not correct. There's no difference between FUSE and other filesystems in this aspect.

Reaching the mountpoint from the root in the first place will require traversing the outer filesystems. That is the only point where those are accessed, and they don't know what the rest of the path is.

2

Of course the system would preventing mounting two things on one directory.

No. You can mount on the same directory as many times as you wish:

mkdir /tmp/foo /tmp/bar /tmp/baz
mount --bind /tmp/foo /tmp/baz
mount --bind /tmp/bar /tmp/baz # <-- no error

But, what if you mount a FUSE program in the top directory and another FUSE program in a sub directory?

The same thing as would happen if the mounts weren't controlled by FUSE programs. The part of the top directory tree that lies "under" the new mount is no longer accessible (except through previously-opened file handles).

My assumption is that it initially goes through operations related to mounting from the top FUSE, and then goes to the actual operations you called in the sub FUSE.

Sort of, yes. The Linux kernel has a "dentry" cache, so if the directories are already in the kernel cache the "top" FUSE program would not necessarily get any events from the mount operation, or from operations taking place in the sub FUSE.

  • I have another question. Assume we call an operation on the sub directory, and the kernel "dentry" cached that sub directory info. Then, if I change the top FUSE to include "deny all read requests" and remount, does that "deny all read request" get ignored because of the cache? Or does it get removed from cache because the top FUSE (which includes the sub FUSE) got unmounted? If so, what if the top FUSE had code that said "only allow one read operation and deny afterwards" so that you can only go to the sub FUSE once? – CuriousKimchi Dec 28 '16 at 8:54
  • 1
    @CuriousKimchi The mount in the subdirectory completely hides whatever was in the upper directory. The top FUSE mount can still mostly prevent access if it makes the mount point impossible to access; but processes that have a handle (e.g. their current directory) in the lower FUSE any time after it's mounted will retain their handle even if the access conditions above the mount point change. – Gilles Dec 28 '16 at 23:26
  • @CuriousKimchi Sometimes, when you have a lot of interacting components, the only way to settle a complex question like your remount example is to run an experiment (and not rely on the results to remain the same if you upgrade your kernel or FUSE implementation). It's also important to remember that path lookups happen on every open. So it's not like a process that has cd to a directory can later open files that have since disappeared from the system's mount tree. – DepressedDaniel Dec 29 '16 at 0:20
  • @CuriousKimchi Interestingly enough, a process that has chrooted under a mountpoint can continue to manipulate files even after the mountpoint has been lazily unmounted. – DepressedDaniel Dec 29 '16 at 0:36
  • @DepressedDaniel I've thought about this for a while, and I don't see how the top FUSE can possibly not get any events from the sub FUSE even if sub FUSE is dentry cached. For example, imagine /mnt/fuse1/fuse2/file where FUSE1 is mounted in /mnt/fuse1, and FUSE2 is mounted in /mnt/fuse1/fuse2. Then, if you try to call read on /mnt/fuse1/fuse2/file even if that path is cached and you no longer need to do a full path-walk, that file is still under /mnt/fuse1 so it will activate FUSE1's read method. Or is that wrong? – CuriousKimchi Jan 2 '17 at 4:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.