If the hack is in a kernel extension, then you’re right—I'd be able to specify the device I mean to interact with (local disk as opposed to unionfs). But, if the hack is in user-space (as it would be with any FUSE fs), then openat is needed to access the on-disk paths beneath the mount point without initiating an infinite loop between the kernel and the unionfs. For now, FUSE+openat sounds more accessible, so I’ll leave the deep dive into kernel extensions for when(if) the project gets beyond a prototype :)
On Fri, Nov 6, 2015 at 8:34 AM, Nikolaus Rath <[email protected]> wrote: > On Nov 06 2015, Cameron Boehmer <[email protected]> wrote: > > On Thu, Nov 5, 2015 at 7:51 PM, Nikolaus Rath <[email protected]> wrote: > > > >> On Nov 04 2015, Cameron Boehmer <[email protected]> wrote: > >> >>>> 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? > >> > > >> > > >> > No, it’ll just keep operating locally and queuing up operations to > send > >> to > >> > the remotes when they come back. > >> > >> You've missed the point. The question was why you'd want to mount the > >> local file system and the union file system at the same path. If the > >> union file system is not unmounted, it does not matter where the local > >> file system is mounted. > >> > > > > Oops—didn’t mean to imply that the localfs gets mounted at all. As you > > noted, by its inclusion in the unionfs, it’s effectively mounted. Maybe I > > was imprecise when referring to the local tree that localfs proxies into > > unionfs. > > Well, in that case you don't need to worry about openat() etc. The only > think you need to do get your holy grail of storage is to hack one of > the union file systems to apply the changes to both underlying file > systems :-). > > 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.
