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 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.
