Emery Hemingway ehmry at posteo.net
Sat Jun 16 11:14:50 CEST 2018

Hello Roman,

Yes, the COW plugin has some known and expected limitations, and thats
my fault. Replicating across immediate file-systems like ram, tar, or
inline should work fine, but replication across the File_system session
is problematic. The issue here is that chaining internal asynchronous
reads and writes is poorly handled when the plugin is used with the VFS
server or internally in Noux.

At the moment the COW plugin is really a simple 'lazy replication'
plugin. True copy-on-write behavior seems to to requires some caching
and state tracking, which was something that was avoided in this early
version. I hope in the next few weeks to move replication to a
background task to improve performance, and that will eliminate the
'block for replication' condition.


On Fri, 15 Jun 2018 16:53:15 +0200
Roman Iten <roman.iten at gapfruit.com> wrote:

> Hello
> I created a vfs package archive containing vfs and vfs_cow and start
> it within the sculpt runtime providing the following configuration:
> <config>
>   <vfs>
>     <dir name="immutable"> <fs label="template_data"/> </dir>
>     <dir name="mutable"> <fs label="user_data"/> </dir>
>     <dir name="cow">
>       <cow ro="/immutable" rw="/mutable"/>
>     </dir>
>   </vfs>
>   <default-policy root="/cow" writeable="yes"/>
> </config>
> Then, I changed the "target" file system of the noux package to use
> the above copy-on-write file system to play around with it...
> First thing I noticed is that the directories and files of
> "template_data" are not populated. I guess that's a feature that is
> not yet or will not be implemented and for my use case it doesn't
> bother me right now.
> But when I open/write a file (that exists in template_data), cow_vfs
> writes the following output:
> [runtime -> cow_fs] Warning: COW: block for replication...
> [runtime -> cow_fs] Warning: COW: block for replication...
> ...and never unblocks afterwards. If immutable is something like
> </ram> or </inline ...>, it works as I would expect it. Is this a
> known limitation? Or can someone point me to the right direction to
> solve it?
> I love the idea of the vfs_cow component and I guess it may cover many
> other use cases!
> Cheers, Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20180616/915c2044/attachment.sig>

More information about the users mailing list