[Top][All Lists]

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

[bug#40236] [PATCH] doc: Suggest Btrfs with compression instead of ext4

From: Efraim Flashner
Subject: [bug#40236] [PATCH] doc: Suggest Btrfs with compression instead of ext4 for root partition.
Date: Thu, 9 Apr 2020 23:12:44 +0300

On Tue, Apr 07, 2020 at 11:18:40PM -0400, Maxim Cournoyer wrote:
> Hello,
> Pierre Neidhardt <address@hidden> writes:
> > Jonathan Brielmaier <address@hidden> writes:
> >
> >> No, I did run openSUSE on btrfs, there was no Guix involved at all. But
> >> btrfs seemed to be the root case of all my troubles (performance,
> >> hang-ups etc).
> I have yet to encounter this kind of problem on the 3 Guix Systems I've
> installed with root Btrfs file systems.  It's been rock stable, even
> under heavy use (I have a Guix machine configured as a Jenkins slave at
> work that builds Yocto projects -- it churns through GiB of files
> daily).
> [...]
> >> Snapshots did fill up my disk.
> Snapshots only fill up the disk when we use them (and leave them behind
> for enough time that the content they refer to has been mostly
> rewritten.
> >> So maybe create a config for the OSes of tomorrow: btrfs, wireguard,
> >> rust etc :P
> >
> > In the end, what I'm suggesting is this issue is merely a
> > recommendation.
> >
> > Currently Guix is very annoying to use on small Ext4 partitions, e.g. a
> > 64 GiB SSD.  With compression on, you suddenly get 3x more space for
> > your /gnu/store :)
> I agree that compression is a nice feature.. It also speeds sequential
> disk reads and writes. On an old laptop that has a 64 GiB SSD and uses
> ext4, I have to 'guix gc' too often, and worry a lot about spaces
> (there's literally not much else than Guix on the drive, but it manages
> to fill it up quite easily :-).

(ins)efraim@E5400 ~$ sudo compsize -x /gnu/store/
Processed 3158140 files, 737675 regular extents (2467369 refs), 1335101 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       74%       51G          69G         180G
none       100%       32G          32G          86G
lzo         51%       19G          36G          93G

My understanding of this is that I have 36GB of files that are
compressed at 51% to 19GB, and overall due to the deduplication in the
store I have references to what would otherwise be 180GB total taking up
only 51G.

So compression saves me 26% ([69-51]/69), and deduplication saves me
62% ([180-69]/180).

Efraim Flashner   <address@hidden>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]