On Wed, Jul 8, 2020 at 11:20 AM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote: > > I expect beefy CPU systems, including gaming systems, to have the same > > or better read/write performance using mount option compress=zstd:1. > > Where I've seen equal or better read performance, there can be a write > > performance drop if the IO storage has been upgraded. Sample size 1, > > and the workload was kernel compiling. > > Yeah I guess for /usr the most relevant write metric is "does it slow down > DNF upgrades or install operations enough to be noticeable / annoying / > problematic"? I'm pretty fussy and impatient. I think I'd notice. But this is not a reliable metric. I think a sane test might be looking at the program.log for a netinstall on lvm+ext4 vs btrfs vs btrfs +compress. Delete the download portion of the test to eliminate network variation error, and only look at payload delivery time. I have done this just today with a Live installation, but this has the problem that we're significantly read bound due to a tightly wound up xz compressed image. That acts as a moderator for whoever is really faster. All these results tell is is that we don't have a problem with live install performance being meaningfully different. https://paste.centos.org/view/7ce7b52f > > SD Card and eMMC it's a win for sure. Also an argument could be made > > do use Btrfs+compression on USB sticks. This class of flash will just > > return garbage if they encounter uncorrectable errors - rather than a > > discrete read error. In this case, Btrfs refuses to hand over the > > corrupt data, in normal operation. A good question is, whether the > > desktop should warn that the file is corrupt, and then permit a > > degraded read somehow to still get the file off the media. It might > > imply necessary desktop integration. > > A related question: Are we planning on using btrfs on live media? No. It will still be ext4 nested in a squashfs image, and rsync to copy. There is/was an idea to move to plain squashfs image, and unsquashfs to copy - but I'm not certain of its status. https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/L6ZQCOYXZOIIOZM7SUFQDGEUEQU2QY7N/ There is a trade off using Btrfs as the image for media. (a) compression won't be as good as plain squashfs, images will get bigger. Maybe as much as 20% - but I've done no optimizing to see if that can be improved. (b) Always on checksumming of the payload we care about (excludes the bootloader, kernel, initramfs for the live environment boot). We can get rid of the long slow one time media checker option. With no meaningful performance hit to the user. And catch even transient corruption due to flakey USB media, etc. (c) We can use rsync for installs to non-btrfs file systems, they still get the benefit of (b); and an optimization for installs to Btrfs is using a seed/sprout replication feature that avoids the decompression/recompression hit of the (b) option because it just copies compressed block groups intact, it's not a file copy. Also these things can be chained (dependently stacked in order; not like independent overlays). https://btrfs.wiki.kernel.org/index.php/Seed-device But yea, as Neal says. Not this cycle. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
