On Nov 03 2015, Cameron Boehmer <[email protected]> wrote:
>> > - *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?!?
Yes.
>> 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.
That sounds rather dangerous. So you want your file system to
self-unmount when it looses network connectivity? You would also need a
watchdog to unmount the file system in case it crashes without
unmounting itself.
But even if you did all that, applications that already opened files or
directories on the unionfs would still hang or crash.
It also sounds rather dangerous to me. The unionfs could basically
disappear "under your feet" at any time. So the user would be safe in
the belief that all his data is duplicated in the cloud, while it's
actually only written to the local disk.
And after this has happened, you'd also need code to recover from the
unplanned unmount. Then you have to deal with synchronization issues: if
you deleted a file on the local fs, how would your unionfs know that it
also has do delete the file remotely? There is no way to distinguish it
from a file that simply didn't happen to be cached.
>> > 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,
I don't know, but my assumption is that it simply looks at the device id
field of the dentry struct.
> and how openat avoids that mechanism…
Openat doesn't use paths but file descriptors, so the above mechanism
never comes into play.
> Do you know of any decent reading material on
> filesystem/kernel basics?
Sorry, nothing specific. But "The Linux Programming Interface" by
Kerrisk and "Understanding the Linux Kernel" by Bovet & Cesati most
likely contain the information somewhere :-).
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 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.
