On Fri, 2021-01-08 at 00:21 -0700, Chris Murphy wrote:
> On Thu, Jan 7, 2021 at 7:52 AM Patrick O'Callaghan
> <pocallag...@gmail.com> wrote:
> > 
> > On Thu, 2021-01-07 at 21:33 +0800, Qiyu Yan wrote:
> > > > and the space usage doesn't seem to have changed.
> > > Try using compsize to get space usage?
> > 
> > # compsize /home
> > Processed 373221 files, 936531 regular extents (1058479 refs), 155981
> > inline.
> > Type       Perc     Disk Usage   Uncompressed Referenced
> > TOTAL       98%      1.1T         1.1T         1.0T
> > none       100%      1.1T         1.1T        1013G
> > zstd        46%       17G          38G          40G
> 
> And are there any new subvolumes you've created below /home? Those are
> not subject to -r, the defragment will stop at subvolume boundaries.
> Any VM images? If they're nodatacow, they won't compress. And quite a
> lot of media files will not compress because they're already
> compressed.

There is one VM image in its own subvolume, as discussed recently. It's
quite large (over 900GB) so that would affect the numbers.

> Based on the above numbers I don't think this is as likely the issue
> but mention it anyway: Are there any snapshots? 'btrfs fi defragment'
> is not snapshot aware and will split up shared extents (makes them
> exclusive again, increasing space consumption).

No snapshots at the moment. From what you say it seems I would need to
consider the tradeoff between using snapshots (e.g. for backup staging)
and compression.

> Lower priority, more experimentation, purely anecdotal: Using zstd:1
> might result in faster writes to SSD; where zstd:3 (same as zstd)
> might result in faster overall writes to HDD. For Fedora 34 the
> proposal is 'compress=zstd:1' and that's a bit conservative but also
> is low hanging fruit with the biggest gain for the effort. Folks who
> don't care about performance or want to use this for archives can
> experiment with even higher values. I tend to use zstd:7 on backups.
> It does get quite slow eventually, around 11 or higher. But zstd is
> fairly invariant to compression level on reads, as in I doubt anyone
> can tell a difference on read between a file that was compressed with
> 1 vs 9, and maybe not notice 15 unless they were paying attention or
> timing it.

OK, thanks.

poc

_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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/users@lists.fedoraproject.org

Reply via email to