Re: Compression on Btrfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 7, 2021 at 7:52 AM Patrick O'Callaghan
<pocallaghan@xxxxxxxxx> 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.

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).

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.


-- 
Chris Murphy
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux