From: Michael K. <mic...@ip...> - 2020-05-01 23:13:15
|
Thanks Lonnie for all your work. I did a random check of my systems and all good as far as no additional binaries added. I do have one site that has binaries added for QueueMetrics but this is in /mnt/kd/bin which I assume will still be fine. I have a few APU1's out there which are certainly slower than APU2's. Are they going to be impacted significantly do you think? Regards Michael Knill On 2/5/20, 4:27 am, "Lonnie Abelbeck" <li...@lo...> wrote: Hi Dev minded folks, We have completed a significant transition from a kernel based unionfs filesystem to a FUSE (in-kernel + userland) unionfs filesystem. A key goal, any change needs to be backward compatible with pre-existing ASTURW partitions. With that, there are a few changes. All good changes, we hope. :-) The old kernel unionfs (via a kernel patch) has not been supported for years, we stretched it's usefulness to the linux kernel 3.16.x, but it is an anchor keeping us from moving to newer kernel versions. We considered a shiny new anchor :-), Aufs, which is also implemented via a kernel patch, more featured/bloated than the previous kernel unionfs and it has targeted support for only select kernel versions. Given the decision for AstLinux to only support 64-bit, x86_64 boards going forward, we wondered how the FUSE unionfs would perform. We gave FUSE unionfs a try on one of the lowest powered x86_64 boards, the PC Engines APU2 ... Previously the full root '/' read-only mount was overlaid with the writable ASTURW partition to yield a read/write filesystem ... unionfs. While FUSE unionfs worked fine as a replacement for a '/' unionfs overlay, the filesystem speed suffered on the APU2, for example reloading the firewall took 3x the time. BTW, the FUSE unionfs is slower since it adds a lot of userland <-> kernel context switches. So then we thought, we really only need (mostly) the '/etc' and '/stat' directories to be overlaid to be made writable, which allowed moving the unionfs mount from the initrd into the /etc/rc startup script. That change returned the APU2 reload firewall performance to nearly it's previous time ... now the '/usr', '/lib', paths are very-slightly faster than before since there is no kernel unionfs overhead, but any '/etc' access is somewhat slower. Overall, no significant filesystem performance difference. So, FUSE unionfs for select directories is the new solution for Astlinux 1.3.10 and onward. No more kernel limiting anchors. This also better secures the filesystem, no accidental (or malicious) changing of '/usr', '/lib', binaries and scripts. The devil is in the details ... Some users may have partitioned their AstLinux installation by selecting "Combined Unionfs and /mnt/kd/ partition", so that is automatically supported when there is no separate ASTKD partition for '/mnt/kd'. Note: New installations now only support "Create separate Unionfs and /mnt/kd/ partitions", which has been the better choice. Some users may have installed binary blobs like codec_g729a.so to the Asterisk /usr/lib/asterisk/modules/ directory. The new default for this directory is to be read-only, but if the user adds ASTERISK_RW_MODULES_DIR="yes" to their user.conf this directory will be overlaid by the ASTURW partition, as it was before. This also creates an easy way to disable incompatible binary blobs from keeping Asterisk from starting. Finally, some homework for those reading this (yes you!). To make sure we did not overlook anything, issue this command: -- show-union all | grep -v -e /asturw/etc -e /asturw/stat -e lost.found -e /asturw/mnt/kd -- You might see -- /oldroot/mnt/asturw /oldroot/mnt/asturw/.rnd /oldroot/mnt/asturw/.asterisk_history -- which can be safely ignored. If you see some '/usr', '/lib', files that may seem important to you, let us know. The AstLinux Team _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |