Vfs import (Re: vfs_cow)

[Roman Iten]

Hi Emery

On 07/26/2018 02:16 PM, Emery Hemingway wrote:
> There is now an "import" VFS plugin that similiar to the COW plugin, but
> with a clearer concept and implmentation. The import plugin will simply
> recursively copy its contents to the root directory of the VFS that is is
> configured in, before the "application" becomes active. The plugin is
> available on the genodelabs/staging branch and we be used in the next
> Sculpt release.

Thanks, I didn't actually try it yet but it looks like it will indeed
cover my use case perfectly! Just one comprehension question regarding
the following configuration:

! <config>
!   <vfs>
!     <fs label="user_data"/>
!     <import>
! 	<fs label="template_data">
!     </import>
!   </vfs>
!   <default-policy root="/" writeable="yes"/>
! </config>

In case "user_data" is a persistent file system, the files and/or
directories that are going to be imported from "template_data" may
already exist in "user_data". Will they remain untouched or are they
overwritten? Or is there an attribute (like <import overwrite|force=...)
to control the behavior?

Thanks, Roman


> On Saturday, June 16, 2018 11:14:50 AM CEST, Emery Hemingway wrote:
>> 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.
>>
>> Cheers,
>> Emery
>>
>> 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: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20180730/aaefabe1/attachment.sig>