On Nov 03 2015, Cameron Boehmer <[email protected]> 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.
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.
