On Wednesday, November 14, 2018 at 6:10:53 PM UTC-5, Waldek Kozaczuk wrote: > > > > On Wednesday, November 14, 2018 at 5:58:16 PM UTC-5, Nadav Har'El wrote: >> >> >> On Wed, Nov 14, 2018 at 9:15 PM Waldek Kozaczuk <[email protected]> >> wrote: >> >>> One of the objectives listed above: >>> "The key building block to achieve it should be an improved ROFS >>> intended as a default filesystem to load code from" >>> is directly related to this. Is it a right move in right direction? I >>> wonder what your thoughts are. >>> >>> >> If I understand you correctly, you want instead of the "ramdisk" located >> inside the kernel (bootfs) and written into a ramfs during boot, to have a >> ROFS partition (or even not an official partition, just an area on the disk >> following the kernel). I am not saying I'm opposed to this, but I'm also >> not sure you'd see major gains from it. Is the default bootfs big enough to >> worry about if we fix https://github.com/cloudius-systems/osv/issues/980 >> (and note that if your image doesn't use ZFS, it wouldn't even have that >> cpiod.so in the bootfs). >> > The major gain is that the kernel will be free on any ZFS code unless one > needs ZFS in which case the ZFS code as a shared library (or other tools > like mkfs.so, cpiod.so, etc) would get loaded from ROFS partition. Same > eventually could apply to NFS. >
I do not want to "beat the dead horse" (maybe not dead yet;-) but another advantage of using rofs instead of bootfs for code, is that such code gets moved outside of kernel and this makes it easier for tools like capstan to build images out of "lego blocks" without having to even start OSv like it is the case with images where the root filesystem is ZFS. The tool like cpiod becomes even less important if we follow the pattern that code lives on rofs and potential data (most likely mutable) lives on zfs. Especially if we make possible for OSv to use ZFS pools created on host (please see this - https://github.com/cloudius-systems/osv/issues/918#issuecomment-379520431). Right now we pivot the root file system in this order: bootfs -> rofs -> zfs, but I would argue we never pivot to zfs and instead let user mount zfs at /data for example using /etc/fstab. This way we will eliminate this "chicken or egg"-type problems and duplication of code on disk and in memory. So concluding if one wants to have pure ramfs image only we would still support and use bootfs for it. Otherwise we would use rofs for code (leave bootfs empty) and optionally mount any other filesystem (zfs, nfs, etc) at whatever non-root mount point user wants. Also it seems to me that very little of what I am saying above requires any major changes to OSv but it is mostly about establishing patterns of how to build images and mount file systems like zfs. Some of it would require changes to tooling. > > >> >> What I still don't understand, though, is how any of these changes will >> allow you to move kernel option parsing from the kernel to an external >> program. Today parse_options() is called very early, because we want to >> support options like "--verbose", "--nomount" and many more, which should >> take effect early - before any filesystem is mounted. I'm not saying fixing >> this is impossible, it's just that I think that option parsing is simple >> enough to rewrite not use boost program options - if you saw that this >> alone can save us half a megabyte (if I remember correctly what you wrote). >> >> That is not what I am trying to say. As you are pointing out it is best > to simply rewrite parse_options() by using getopt_long() instead of program > options. And I agree with this. The is however second part in loader.cc > that uses program options - to parse command line with possible runscript > option (most of commands.cc). That is what I propose to extract as an > optional commands.so that could be loaded from ROFS as well. I hope it > makes it clear. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
