From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:45708) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOBD9-0005sc-BD for guix-patches@gnu.org; Mon, 13 Apr 2020 22:22:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jOBD8-0001SQ-BG for guix-patches@gnu.org; Mon, 13 Apr 2020 22:22:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49631) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jOBD8-0001SM-80 for guix-patches@gnu.org; Mon, 13 Apr 2020 22:22:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jOBD8-0002um-4t for guix-patches@gnu.org; Mon, 13 Apr 2020 22:22:02 -0400 Subject: [bug#40236] [PATCH] doc: Suggest Btrfs with compression instead of ext4 for root partition. Resent-Message-ID: From: Maxim Cournoyer References: <87lfnesxp6.fsf@gnu.org> <87pncqbbp5.fsf@ambrevar.xyz> <87zhbuqpns.fsf@gnu.org> <87y2rc6nuk.fsf@gmail.com> <87r1x0welb.fsf@ambrevar.xyz> <87o8s3wz7d.fsf@ambrevar.xyz> <87o8s2k6lr.fsf@gmail.com> <20200409201244.GR1518@E5400> <87o8rzvlg9.fsf@ambrevar.xyz> <20200410082425.GA1518@E5400> <87eesvvhim.fsf@ambrevar.xyz> Date: Mon, 13 Apr 2020 22:20:53 -0400 In-Reply-To: <87eesvvhim.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Fri, 10 Apr 2020 11:04:17 +0200") Message-ID: <87h7xmiz96.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Pierre Neidhardt Cc: 40236@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= , Efraim Flashner , Jonathan Brielmaier Hi! Pierre Neidhardt writes: > Efraim Flashner writes: > >> On Fri, Apr 10, 2020 at 09:39:18AM +0200, Pierre Neidhardt wrote: >>> > So compression saves me 26% ([69-51]/69), and deduplication saves me >>> > 62% ([180-69]/180). >>> >>> Thanks for sharing! >>> zstd might give better results. Any reason you chose lzo over zstd? >>> >> >> My machine is about 10 years old so I was more concerned than normal >> about the CPU usage. If lz4 was an option I would've gone with that, but >> according to the Arch wiki or some other locations lzo was basically the >> fastest option. > > I've tried zstd on an AMD Athlon II X4 635 (2010): it's perfectly > smooth, can't notice any performance drop. In fact, I wonder if it's > not even faster than before, but it's hard to measure. I've also tried zstd (default level, 3) on a Intel Q6700 desktop (2007). I don't see any CPU spike caused by the compression. It's operating quite smoothly actually, and gives me the following space savings: --8<---------------cut here---------------start------------->8--- sudo compsize -x /gnu/store Processed 1613194 files, 402674 regular extents (1163093 refs), 665696 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 60% 15G 25G 63G none 100% 10G 10G 28G zstd 33% 5.1G 15G 34G --8<---------------cut here---------------end--------------->8--- Recently on the #btrfs channel someone suggested to use the Btrfs option compress-force=zstd rather than compress=zstd, the reason being that zstd has its own algorithm to determine if it should compress a file or not, and that this is faster than what Btrfs does on its own when trying to test for compressibility. Another suggestion was to use space_cache=v2 (it defaults to v1). This is supposedly more efficient at managing the free space pool on large drives (TB and up). Maxim