s3ql: almost the holy grail?

[Cameron Boehmer]

Hey guys,

First, this project looks incredible! Thanks to all the contributors :) Second, after a brief encounter with the FAQ, I don't think s3ql does what I want, but it's so close that I want to lay out my goals—I can't be the first seeker on this path...

My goal: the holy grail of personal storage.

• local file system is effectively infinite (backed by s3, etc)
• has all the nice things like compression, client-side encryption, snapshotting, multiple remotes/subtrees
• reading a file stored on a remote fs downloads that file to the local filesystem at the same path 
• another way to say this is that the local filesystem acts a bit like an LRU cache for remote paths

s3ql looks perfect except for the last point. The FAQ says that the closest it comes to this is using rsync to copy local data into an s3ql mount, but that won't let you see remote files next to local ones, let alone make them local transparently.

Given that it's addressed in the FAQ, I assume it's been discussed, so why is this the case? This is not idle curiosity talking—I've been working on a rough draft of the above (python + fuse), but I don't want to re-implement all the beautiful stuff in s3ql if I don't have to. 

Cheers,

Cameron

[Nikolaus Rath]

On Oct 31 2015, Cameron Boehmer <cameron...@gmail.com> wrote:
> Hey guys,
>
> First, this project looks incredible! Thanks to all the contributors :)
> Second, after a brief encounter with the FAQ, I don't think s3ql does what

> I want, but it's *so close *that I want to lay out my goals—I can't be the

> first seeker on this path...

Let's see what we can do. I think your main problem is that your goals
are a little ill-defined:

> My goal: the holy grail of personal storage.
>

> - local file system is effectively infinite (backed by s3, etc)

That is already a contradiction. Either the file system is *local*, then
it's finite and *not* backed by a remote service, or it is *remote*.

> - reading a file stored on a remote fs downloads that file to the local
> filesystem *at the same path*

That is impossible by definition. On any path there can be only one file
system mounted.

> - another way to say this is that the local filesystem acts a bit

> like an LRU cache for remote paths

..and this is mostly what S3Ql does, only the cache is not in the same
location (because that's impossible by definition), and the cache is
flushed on umount.

> s3ql looks perfect *except* for the last point. The FAQ says that the

> closest it comes to this is using rsync to copy local data into an s3ql
> mount, but that won't let you see remote files next to local ones, let
> alone make them local transparently.

I'm going to take a wild guess here and describe in my words what I
think you want:

* You want two file systems, one locally and one remote
* You want to have an union file system (like unionfs), that "merges"
the two file systems, and where files from the local fs take
precedence.
* You want writes to the union to be propagated to both the local and
remote fs
* Occasionally, you want to delete files from the local fs that have
not been accessed for a while

Is that correct? In that case (as the description already implies), I
would take a look at the various union/overlay file systems to see if
any of them already does what you want. The only thing that might be
missing is the ability to write to both backing file systems. You could
either hack that yourself, or periodically run rsync from the local
backing filesystem to the remote backing filesystem. For the expiration,
a cron-job would do.


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

[Cameron Boehmer]

I'm going to take a wild guess here and describe in my words what I

think you want:

 * You want two file systems, one locally and one remote
 * You want to have an union file system (like unionfs), that "merges"
   the two file systems, and where files from the local fs take
   precedence.
 * You want writes to the union to be propagated to both the local and
   remote fs
 * Occasionally, you want to delete files from the local fs that have
   not been accessed for a while

Is that correct? In that case (as the description already implies), I
would take a look at the various union/overlay file systems to see if
any of them already does what you want. The only thing that might be
missing is the ability to write to both backing file systems. You could
either hack that yourself, or periodically run rsync from the local
backing filesystem to the remote backing filesystem. For the expiration,
a cron-job would do.

You definitely got the gist, except for two pieces, both of which I've found lacking in other solutions (including unionfs), and both of which are at the core of my desire:

• reads from the remote fs should populate the local fs
• should be easy to do this wherever write propagation is implemented
• the mount point of the merged fs should be the same as the root of the local fs

The last point, the one you mentioned is impossible, is the lynchpin. 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. That, of course, rests upon the assumption that the kernel can interact with the "real" filesystem directly and bypass the FUSE filesystem. If that is not possible, I would love to know why!

Thank you SO MUCH, Nikolaus :)

Cameron 

[Nikolaus Rath]

On Nov 03 2015, Cameron Boehmer <cameron...@gmail.com> wrote:
>>
>> I'm going to take a wild guess here and describe in my words what I
>> think you want:
>>
>> * You want two file systems, one locally and one remote
>> * You want to have an union file system (like unionfs), that "merges"
>> the two file systems, and where files from the local fs take
>> precedence.
>> * You want writes to the union to be propagated to both the local and
>> remote fs
>> * Occasionally, you want to delete files from the local fs that have
>> not been accessed for a while
>>
>> Is that correct? In that case (as the description already implies), I
>> would take a look at the various union/overlay file systems to see if
>> any of them already does what you want. The only thing that might be
>> missing is the ability to write to both backing file systems. You could
>> either hack that yourself, or periodically run rsync from the local
>> backing filesystem to the remote backing filesystem. For the expiration,
>> a cron-job would do.
>>
>
> You definitely got the gist, except for two pieces, both of which I've
> found lacking in other solutions (including unionfs), and both of which are
> at the core of my desire:
>

> - reads from the remote fs should populate the local fs
> - should be easy to do this wherever write propagation is
> implemented

Indeed. Happy hacking! :-).

> - *the mount point of the merged fs should be the same as the root of
> the local fs*

Why?

> The last point, the one you mentioned is impossible, is the lynchpin.

No, it is possible (note the subtle difference to how you originally
phrased it). You can open a file descriptor to the root of the local
file system, mount the union fs over it, and then transfer the file
descriptor to the process handling the union fs. The local fs will no
longer be directly accessible, but a process with an already opened fd
can openat() et al to still access it.

But what would be the advantage of simply mounting the local file system
somewhere else?

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

[Cameron Boehmer]

>    - *the mount point of the merged fs should be the same as the root of
>    the local fs*

Why?

> The last point, the one you mentioned is impossible, is the lynchpin.

No, it is possible (note the subtle difference to how you originally
phrased it). You can open a file descriptor to the root of the local
file system, mount the union fs over it, and then transfer the file
descriptor to the process handling the union fs. The local fs will no
longer be directly accessible, but a process with an already opened fd
can openat() et al to still access it.

Oh boy! I think this means I can do what I want without writing kernel code?!? 

 

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.

 

> 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, and how openat avoids that mechanism… Do you know of any decent reading material on filesystem/kernel basics? I hate to pepper you with questions like this is office hours. 

Cheers,

Cameron

 

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 s3ql+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nikolaus Rath]

On Nov 03 2015, Cameron Boehmer <cameron...@gmail.com> wrote:

>> > - *the mount point of the merged fs should be the same as the root of
>> > the local fs*
>>
>> Why?
>>
>> > The last point, the one you mentioned is impossible, is the lynchpin.
>>
>> No, it is possible (note the subtle difference to how you originally
>> phrased it). You can open a file descriptor to the root of the local
>> file system, mount the union fs over it, and then transfer the file
>> descriptor to the process handling the union fs. The local fs will no
>> longer be directly accessible, but a process with an already opened fd
>> can openat() et al to still access it.
>
> Oh boy! I think this means I can do what I want without writing kernel
> code?!?

Yes.

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

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.

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.

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

[Cameron Boehmer]

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

[Nikolaus Rath]

On Nov 04 2015, Cameron Boehmer <cameron...@gmail.com> 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.

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

Again, then why worry about where the local fs is mounted?


Best,
-Nikolaus

[Cameron Boehmer]

On Thu, Nov 5, 2015 at 7:51 PM, Nikolaus Rath <Niko...@rath.org> wrote:

On Nov 04 2015, Cameron Boehmer <cameron...@gmail.com> 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. 

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

Again, then why worry about where the local fs is mounted?


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

[Nikolaus Rath]

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

[Cameron Boehmer]

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 :)

[Nikolaus Rath]

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

[Cameron Boehmer]

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. 

[Brad Knowles]

On Nov 6, 2015, at 10:34 AM, Nikolaus Rath <Niko...@rath.org> wrote:

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

Or maybe use ExpanDrive?

--
Brad Knowles <br...@shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

[Cameron Boehmer]

Hey Brad,

Thanks for mentioning ExpanDrive. Based on the marketing materials, it looks very similar to s3ql. What makes it different? 

Cameron

[Brad Knowles]

On Nov 8, 2015, at 4:33 PM, Cameron Boehmer <cameron...@gmail.com> wrote:

> Thanks for mentioning ExpanDrive. Based on the marketing materials, it looks very similar to s3ql. What makes it different?

It doesn’t do compression or de-duplication, but ExpanDrive does connect to a number of back-end services, and I believe that it provides the caching functionality that I seem to recall your wanting.

[Nikolaus Rath]

[Quoting and line wrapping repaired]

On Nov 08 2015, Cameron Boehmer <cameron...@gmail.com> wrote:
> On Sun, Nov 8, 2015 at 7:37 AM, Nikolaus Rath <Niko...@rath.org> wrote:
>
>> On Nov 06 2015, Cameron Boehmer <cameron...@gmail.com> wrote:
>> > On Fri, Nov 6, 2015 at 8:34 AM, Nikolaus Rath <Niko...@rath.org> wrote:
>> >> On Nov 06 2015, Cameron Boehmer <cameron...@gmail.com> wrote:
>> >> > On Thu, Nov 5, 2015 at 7:51 PM, Nikolaus Rath <Niko...@rath.org> wrote:
>> >> >> On Nov 04 2015, Cameron Boehmer <cameron...@gmail.com> 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 :-).

[Cameron Boehmer]

Looks like there's more confusion than I have time to clear up (sorry!), but to recap, I arrived here wanting to mount a filesystem that can expose and modify on-disk paths beneath its mount point. I'm equally thankful for the solution (openat et al) as I am for the help in articulating the goal.

If you're curious why I want such a thing, well, as I've said, I'd like to write user-space filesystems that leave their contents "in place" after the FUSE process terminates. 

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

"The former" refers to the first of two mentioned things, in this case the root. ("The latter" could be used to refer to the second.) "It" is the localfs.

Cheers,

Cameron

[Nikolaus Rath]

On Nov 11 2015, Cameron Boehmer <cameron...@gmail.com> wrote:
> I arrived here wanting to mount a filesystem that can expose
> and modify on-disk paths beneath its mount point.

Sounds like ext4 will satisfy all your needs then :-).

> If you're curious *why* I want such a thing, well, as I've said, I'd like

> to write user-space filesystems that leave their contents "in place" after
> the FUSE process terminates.

Which is a bad idea for several reasons:

* If the file system crashes, the mountpoint will become inaccessible
(rather than revert to whatever the mount was shadowing)

* If the file system terminates regularly (and unmounts), applications
that already opened files or directories on the mountpoint still hang
or crash.

* From a user perspective, you would never be able to tell if you are
working through the userspace file system or not (which, dependending
on the purpose of the userspace file system easily nullifies the
advantage. E.g. if you want to store the data in two places for
redundancy you could not actually rely on it).

* If the purpose is to keep the data stored in two places (which I
believe you want to do), you need additional complexity to handle
synchronization issues. Otherwise you cannot tell if a file has been
deleted in one place (and should be deleted in the other) or if it
has been created in the other.