I don’t think so. What I said is that the localfs doesn’t need its *own* mount point, so long as its included in the mounted unionfs:
> didn’t mean to imply that the localfs gets mounted at all. By its inclusion in the unionfs, it’s effectively mounted. Are you confusing the localfs root with its mount point? The former is the on-disk directory tree it manages. To clarify my last email, assuming localfs is a user-space fs, if there’s any fs mounted at the localfs root, then localfs needs openat et al to make sure its disk operations don’t get handled by whatever controls the mount point masking its root. On Sun, Nov 8, 2015 at 7:37 AM, Nikolaus Rath <[email protected]> wrote: > On Nov 06 2015, Cameron Boehmer <[email protected]> wrote: > > 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 :-). > > > > 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 :) > > You're still confused. Just one email ago you agreed that you don't need > to mount the local file system at the same path as the union file > system. > > > 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.
