> > - *the mount point of the merged fs should be the same as the root of > > the local fs* > > Why? > > > The last point, the one you mentioned is impossible, is the lynchpin. > > No, it is possible (note the subtle difference to how you originally > phrased it). You can open a file descriptor to the root of the local > file system, mount the union fs over it, and then transfer the file > descriptor to the process handling the union fs. The local fs will no > longer be directly accessible, but a process with an already opened fd > can openat() et al to still access it. >
Oh boy! I think this means I can do what I want without writing kernel code?!? > > But what would be the advantage of simply mounting the local file system > somewhere else? > E.g., I would like a user to be able to mount this unionfs at ~/ and feel confident that the fs process could crash, the network or remote service could go away at any moment, and the files they’ve been interacting with will still be there on the local disk, exactly where they were left. > > > After reading FUSE's docs, it would seem possible to do so by > > modifying the kernel extension to not just intercept and forward > > system calls to paths beneath the mounted FUSE subtree, but to support > > interacting with local "on-disk" paths. > > You have the wrong idea. The kernel is not intercepting anything. FUSE > is a file system like any other. > An excellent clarification, which prompts me to wonder by what mechanism the kernel decides which filesystem to consult for a given path, and how openat avoids that mechanism… Do you know of any decent reading material on filesystem/kernel basics? I hate to pepper you with questions like this is office hours. Cheers, Cameron > > > Best, > -Nikolaus > > -- > GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F > Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > > -- > You received this message because you are subscribed to a topic in the > Google Groups "s3ql" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/s3ql/S9_ETpoemDs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
