On Friday, September 18, 2020 at 11:30:28 PM UTC+3 jwkoz...@gmail.com wrote:
> On Friday, September 18, 2020 at 6:10:48 AM UTC-4 Fotis Xenakis wrote: > >> Στις Δευτέρα, 14 Σεπτεμβρίου 2020 στις 7:49:50 μ.μ. UTC+2, ο χρήστης >> jwkoz...@gmail.com έγραψε: >> >>> Hey, >>> >>> Thanks for your patches. I love how you improved build/run export mode >>> to make it easier to run OSv apps from virtio-fs. >>> >>> On Thu, Sep 3, 2020 at 6:25 PM Fotis Xenakis <fo...@windowslive.com> >>> wrote: >>> >>>> Changes since v1: >>>> - Made the loader backwards compatible: if the --rootfs flag is not >>>> specified, it fals back to the previous behavior of trying to mount >>>> rofs, followed by zfs. >>>> >>>> On the root filesystem selection front, the thought of generalizing the >>>> current implementation to try out the other fs as well when --rootfs is >>>> not specified has passed through my mind. This could be a basic >>>> auto-discovery process and should be straight-forward as long as the >>>> various mount_*_rootfs are side-effect free when they fail. Do you think >>>> it's something worth pursuing? >>>> >>> That sounds like a good idea. In essence, you would like to enhance the >>> current default pseudo discovery mode where it first tries rofs and then >>> zfs, right? You would add virtiofs to it, right? Please note that ZFS is >>> most expensive in terms of boot time (not sure comparing to virtiofs) so I >>> would keep it last. Hopefully, you would not need to spend any time trying >>> to boot from virtio-fs if there is no virtioFS device present. >>> >> Exactly as you describe. After a quick profiling of the mount times (both >> successful and unsuccessful) for each of the filesystems, I see that: >> - ROFS and virtio-fs are pretty quick to mount (successfully): 1.5-2ms on >> my laptop (<1% of total boot time). On the other hand, ZFS is a lot slower >> (~65ms, or ~20%). >> - When, during auto-discovering, a mount fails, it takes negligible time >> for ROFS and virtio-fs (0.01-0.05ms) and somewhat more (~1.2ms, ~0.5%) for >> ZFS. >> So, the point is: >> - ROFS and virtio-fs are on par regarding mounting performance. >> - ZFS is slower, but when it fails it's not too bad. >> >> The most backwards-compatible choice would be to try virtio-fs only after >> ROFS and ZFS have failed. Yet, this would add a <1% overhead when >> discovering virtio-fs. The alternative would be to try virtio-fs before ZFS >> (or before ROFS), exchanging backwards compatibility for negligible >> overhead. Which do you think best? >> > ROFS, then virtio-fs, then ZFS. > A patch addressing this has finally been posted. > >>> Relatedly, do you know if the virtiofs team has made any changes to make >>> it possible to expose/assess virtiofs without having to run it as a >>> privileged user? I would imagine it raises some security concerns. >>> >> I haven't gotten in touch with them recently regarding this matter, but >> their qemu development branches haven't been updated recently either and no >> obvious relevant update has been posted in the virtio-fs mailing list. So, >> I assume not much has changed unfortunately. >> >>> >>>> Fotis Xenakis (3): >>>> loader: add rootfs type command line option >>>> loader: add support for booting from virtio-fs >>>> scripts/build: don't exit when exporting files >>>> >>>> fs/vfs/main.cc | 26 ++++++++++++++++++- >>>> loader.cc | 68 ++++++++++++++++++++++++++++++++++++++++++-------- >>>> scripts/build | 26 +++++++++++++------ >>>> 3 files changed, 101 insertions(+), 19 deletions(-) >>>> >>>> -- >>>> 2.28.0 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "OSv Development" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to osv-dev+u...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/osv-dev/AM0PR03MB62927D3618586AE600B4FBE1A62C0%40AM0PR03MB6292.eurprd03.prod.outlook.com >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/5da7601a-a7d1-4749-a39d-89ccb1c940cfn%40googlegroups.com.
