> 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?
No, it’ll just keep operating locally and queuing up operations to send to the remotes when they come back. > 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. > That’s true for any filesystem, no? I.e., try not to 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. > My primary goal is to make sure that the local disk reflects the user’s recent activity in as many failure modes as possible. Syncing to remotes is secondary to the local disk acting like a 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. > I can imagine writing an op queue to disk, or other stateful recovery solutions, but honestly it doesn’t seem that important. I don’t think anyone would be too surprised to find a file they thought they deleted is still around after a crash. It’s certainly better than recently read/written files disappearing! > >> > 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 :-). > You’re kind to omit a lmgtfy link :) > > Best, > -Nikolaus > > You’re a rockstar, Nik. Thanks for all the help. Cheers, Cameron > -- > 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.
