[Quoting and line wrapping repaired]
On Nov 08 2015, Cameron Boehmer <[email protected]> wrote:
> 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
That should of course have been "advantage over"
>> >> >> >>>> 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.
In that case you can't access it at all (not even indirectly through the
unionfs).
>>>>> As you noted, by its inclusion in the unionfs, it’s effectively
>>>>> mounted.
No, that's not what happens (and hopefully also not what I said).
>> >> > 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.
>
> 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:
In that case I still don't understand why you'd want that extra
complication. What do you gain? Having a separate mountpoint for the
local file system makes things much easier.
> didn’t mean to imply that the localfs gets mounted at all. By its
> inclusion in the unionfs, it’s effectively mounted.
Unless you want your unionfs to re-implement e.g. ext4 and open the
block device directly, this is not how it works. A unionfs takes two
*paths* and presents a merged version. Typically, these paths happen to
be mountpoints. And typically, the unionfs must not be mounted in a
place that shadows either of the paths. You can avoid the latter
restriction by using openat - but to what end?
> Are you confusing the localfs root with its mount point? The former is the
> on-disk directory tree it manages.
The second sentence doesn't make sense to me. "The mount point is the
on-disk directory tree it manages"? What's "it" here? Also, a mountpoint
is *not* a directry tree on a disk, it is a path at which the root
directory of a file system has been attached in the system's directory
tree (i.e, it exists purely in memory).
> To clarify my last email, assuming localfs is a user-space fs, if there’s
> any fs mounted at the localfs root,
That sentence doesn't make sense. If with "localfs" root you mean the
on-disk structure, then nothing can be "mounted" there ("mounting" isn't
done in a file system but in the VFS). If with "localfs root" you mean
the path where localfs is mounted (i.e, it's mountpoint) then a file
system is mounted there by definition.
> then localfs needs openat et al to make
> sure its disk operations
If localfs is a local fs, then it's disk operations access a block
device that's opened once on moint.
I think you still have some wrong ideas about how file systems and/or
FUSE works in Linux :-).
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.
