Re: [Astlinux-devel] Important: unionfs change

[David K. <da...@ke...>]

Lonnie,
  Great work. I see lots of updates in github so you have been very busy.
A question on the combined unionfs and /mnt/kd (as I think that is how I
originally installed -- how would I tell?).  When installing your newest
build will this combined partition be un-combined and so our existing
systems will have the same filesystem layout as a newly installed system?
If not is there a way to manually make the change?

Thanks
David


On Fri, May 1, 2020 at 2:27 PM 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
>