On Wed, Jul 8, 2020 at 1:20 PM Matthew Miller <mattdm(a)fedoraproject.org> 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"?
> 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?
Not for this change, no. Part of the reason is that I didn't want to
bite off more than I can chew, and part of it is that I want to
explore some of the Btrfs-specific enhancements with seed images and
the seed/sprout flow before I go down that road.
There's some seriously cool opportunities there, but I want to
actually try it before I propose it. :)
We are, however, changing all the disk image deliverables to Btrfs
(like the ARM ones), since that's how people wind up using it anyway.
--
真実はいつも一つ!/ Always, there's only one truth!