<div dir="ltr"><div>The performance hit for BTRFS put me off. I already have issues on this hardware with Nextcloud struggling (although the overhead of the VMs won't be helping).<br></div><div><br></div><div>If you want container fun, you might like this:
<span style="font-size:11pt;font-family:"Calibri",sans-serif"><a href="https://iximiuz.com/en/posts/you-dont-need-an-image-to-run-a-container/" style="color:rgb(5,99,193);text-decoration:underline">https://iximiuz.com/en/posts/you-dont-need-an-image-to-run-a-container/</a><br></span></div><div>systemd can also run containers directly (which isn't as mad as it sounds) but I know how you feel about systemd.<br></div><div><span style="font-size:11pt;font-family:"Calibri",sans-serif"></span>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 May 2020 at 01:57, Martin via Nottingham <<a href="mailto:nottingham@mailman.lug.org.uk">nottingham@mailman.lug.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Surprised noone gave further comment on this...<br>
<br>
<br>
On 18/05/2020 21:27, Jason via Nottingham wrote:<br>
> Papped it all on to Ext4 and ran the first set of transfers. ~330Mbps?<br>
> Not too shabby considering the hardware.<br>
<br>
Good stuff!<br>
<br>
Ya Kannae ga astrae wi ext4! :-)<br>
<br>
<br>
> KVM and some other stuff to go and the decide on exactly how to switch<br>
> to Containers. I was going to use Rancher, but that freaks if you use<br>
> ".local". Portainer is an option, but I've found that clunky for upgrades.<br>
> <br>
> Fun times.<br>
<br>
Have fun!<br>
<br>
I'll be jumping into containers sometime or other.<br>
<br>
<br>
<br>
To summarise my use of filesystems:<br>
<br>
ext4 for /boot;<br>
<br>
btrfs for everything else for both SSD and HDD;<br>
<br>
f2fs for flash media and for 1st gen (old!) SSDs.<br>
<br>
<br>
The ext4 is for historic reasons and for easy disaster recovery;<br>
<br>
btrfs is easily now mainstream and is good/best regardless of whether<br>
you ever wish to use the snapshot features. It becomes a must-use for<br>
large RAID arrays.<br>
<br>
(RAID using mdraid and/or drbd are 'bomb-proof' but the repair/rebuild<br>
times become unwieldy and unsafe as the arrays become ever larger...)<br>
<br>
The only 'gotcha' for btrfs is that if you are going to use large VM<br>
disk images or large databases, then you need to set the working<br>
directories for those to be "chattr -C" to disable the btrfs CoW<br>
functionality for those particular directory trees so as to avoid the<br>
inevitable high fragmentation for CoW-ing live disk images and large<br>
database files. What counts as 'large' is relative to your system...<br>
<br>
btrfs has some beautiful future-proofing features that support very easy<br>
upgrading and migration to new hardware and/or other systems.<br>
<br>
You can convert an existing ext4 filesystem directly in place into a<br>
btrfs filesystem, such is the inherent flexibility.<br>
<br>
<br>
Filesystem developments to watch developing are:<br>
<br>
the snapshots being added to f2fs;<br>
<br>
and there is bcachefs to check out when developed further.<br>
<br>
<br>
<br>
And then there are other fun stuff such as hadoop...<br>
<br>
<br>
Good luck!<br>
Martin<br>
<br>
-- <br>
Nottingham mailing list<br>
<a href="mailto:Nottingham@mailman.lug.org.uk" target="_blank">Nottingham@mailman.lug.org.uk</a><br>
<a href="https://mailman.lug.org.uk/mailman/listinfo/nottingham" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/nottingham</a></blockquote></div>