[-- Attachment #1.1: Type: text/plain, Size: 3165 bytes --] ## Overview When using --expose to mirror a path between host and guest, the guest mirror fails to reflect file modifications from the host. However, file creation and deletion are correctly propogated. To pick up file modifications in the guest, it is sufficient to remount mirroring 9p filesystem. Is this behaviour expected? ## Reproduction The following should be sufficient to reproduce the issue: Create a container and expose a path: host$ guix system --expose /some/path vm.scm /gnu/store/<hash>-run-vm.sh Spin up the vm: host$ /gnu/store/<hash>-run-vm.sh From the host, create a new file under /some/path, and check that the guest sees this file: host$ touch /some/path/test guest$ cat /some/path/test <file is empty> Now change the contents of this file on the host, and verify that the guest does not see the change: host$ echo foo >/some/path/test guest$ cat /some/path/test <file is empty> Finally, remount the filesystem at /some/path, and see that the guest now picks up the changes: guest$ sudo mount -o remount,ro /some/path guest$ cat /some/path/test foo ## Version Information $ guix describe Generation 123 Aug 25 2020 23:19:12 (current) guix 253fcfe repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 253fcfe6fec8fb9d70cde8623fe562dc3ca67262 $ cat vm.scm (use-modules (gnu)) (use-service-modules networking ssh) (use-package-modules admin linux ncurses tmux) (operating-system (host-name "fmadio") (timezone "Asia/Tokyo") (locale "en_US.utf8") (bootloader (bootloader-configuration (bootloader #f) (target #f))) (kernel linux-libre-4.9) (file-systems %base-file-systems) (users (cons (user-account (name "x") (password (crypt "x" "Jr1er07l0lOUQ95GQLijow==")) (group "users") (supplementary-groups '("wheel"))) %base-user-accounts)) (packages (cons* ncurses tcpdump tmux %base-packages)) (services (cons* (service dhcp-client-service-type) (service openssh-service-type) %base-services))) ## Notes In the above, I am running linux-libre@4.9 in the guest, but another user on #guix confirmed the issue with linux-libre@5.8. The same user reported seeing the following after modifying the host file and remounting in the guest: guest$ cat /some/path/test [ 49.263620] FS-Cache: Duplicate cookie detected [ 49.263644] FS-Cache: O-cookie c=00000000fe189610 [p=000000004224ad86 fl=226 nc=0 na=1] [ 49.263664] FS-Cache: O-cookie d=0000000023080181 n=00000000825c3154 [ 49.263680] FS-Cache: O-key=[8] 'c3f51c0500000000' [ 49.263695] FS-Cache: N-cookie c=00000000c11e31c7 [p=000000004224ad86 fl=2 nc=0 na=1] [ 49.263715] FS-Cache: N-cookie d=0000000023080181 n=00000000dad562d4 [ 49.263731] FS-Cache: N-key=[8] 'c3f51c0500000000' foo [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 730 bytes --] Hi, elaexuotee--- via Bug reports for GNU Guix <bug-guix@gnu.org> skribis: > When using --expose to mirror a path between host and guest, the guest mirror > fails to reflect file modifications from the host. However, file creation and > deletion are correctly propogated. > > To pick up file modifications in the guest, it is sufficient to remount > mirroring 9p filesystem. > > Is this behaviour expected? I believe this comes from the “cache=loose” 9p mount option added in commit e0d96774dd48c29ccc4c90fea1f8f71850ab0879. Does the patch below help? Chris, what do you think? How would this affect the performance issues that led to e0d96774dd48c29ccc4c90fea1f8f71850ab0879? Thanks, Ludo’. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 529 bytes --] diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm index 861f2a427a..80a8618729 100644 --- a/gnu/system/vm.scm +++ b/gnu/system/vm.scm @@ -699,7 +699,8 @@ of the GNU system as described by OS." (device (file-system->mount-tag source)) (type "9p") (flags (if writable? '() '(read-only))) - (options "trans=virtio,cache=loose") + (options (string-append "trans=virtio" + (if writable? "" ",cache=loose"))) (check? #f) (create-mount-point? #t)))))
[-- Attachment #1.1: Type: text/plain, Size: 341 bytes --] > I believe this comes from the “cache=loose” 9p mount option added in > commit e0d96774dd48c29ccc4c90fea1f8f71850ab0879. > > Does the patch below help? Yes, when no caching behaviour is specified in the guest, the problem disappears. I also tried cache=fscache and see the exact same problem as with cache=loose. Cheers! [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 924 bytes --] Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > elaexuotee--- via Bug reports for GNU Guix <bug-guix@gnu.org> skribis: > >> When using --expose to mirror a path between host and guest, the guest mirror >> fails to reflect file modifications from the host. However, file creation and >> deletion are correctly propogated. >> >> To pick up file modifications in the guest, it is sufficient to remount >> mirroring 9p filesystem. >> >> Is this behaviour expected? > > I believe this comes from the “cache=loose” 9p mount option added in > commit e0d96774dd48c29ccc4c90fea1f8f71850ab0879. > > Does the patch below help? > > Chris, what do you think? How would this affect the performance issues > that led to e0d96774dd48c29ccc4c90fea1f8f71850ab0879? Caching only for readonly filesystems sounds fine, I think I was only thinking about the store for e0d96774dd48c29ccc4c90fea1f8f71850ab0879. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 962 bytes --]
Hello!
Christopher Baines <mail@cbaines.net> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi,
>>
>> elaexuotee--- via Bug reports for GNU Guix <bug-guix@gnu.org> skribis:
>>
>>> When using --expose to mirror a path between host and guest, the guest mirror
>>> fails to reflect file modifications from the host. However, file creation and
>>> deletion are correctly propogated.
>>>
>>> To pick up file modifications in the guest, it is sufficient to remount
>>> mirroring 9p filesystem.
>>>
>>> Is this behaviour expected?
>>
>> I believe this comes from the “cache=loose” 9p mount option added in
>> commit e0d96774dd48c29ccc4c90fea1f8f71850ab0879.
>>
>> Does the patch below help?
>>
>> Chris, what do you think? How would this affect the performance issues
>> that led to e0d96774dd48c29ccc4c90fea1f8f71850ab0879?
>
> Caching only for readonly filesystems sounds fine, I think I was only
> thinking about the store for e0d96774dd48c29ccc4c90fea1f8f71850ab0879.
Alright, I went ahead and did that in
7eeb78157d3d0267ce4a4ea38ff56a2c4246c11b.
Thanks!
Ludo’.