From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 16:54:01 2021 Received: (at 51787) by debbugs.gnu.org; 20 Dec 2021 21:54:01 +0000 Received: from localhost ([127.0.0.1]:51634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzQbY-0007ts-Rv for submit@debbugs.gnu.org; Mon, 20 Dec 2021 16:54:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzQbS-0007tX-9s for 51787@debbugs.gnu.org; Mon, 20 Dec 2021 16:53:59 -0500 Received: from [2001:470:142:3::e] (port=55258 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzQbM-0005ik-QZ; Mon, 20 Dec 2021 16:53:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=uTgwFC3wdEK6Obpgdn4wflDZoTIA19yh2eJfX+NHy/g=; b=BM28vqNDzd71YYXEtssX bABIGjr8gtvsckskOehLOUhXVajeSojnYi2F3Hiv/jslfNn9C97XdYcU3+4zK/t3FsGrlSL5Rz9C7 cjc7k9j/hvgqnCCYT/kSaPDzryh9MKrPHOtnpQmtEf0BVWN8GdjTzgRoJWUwvfArqjg6FYpDqCvR6 jVlNRISLBu/RvztBA/1d7kd887+fuopRzsDw6DjNKedFPSBu60ffM6vC7xdEE9IEfm1Y/dzrSMnmY ffLVNQlJ1+TJBA0hs9+hNBDYenrd0GqNNeN+JeAbYgz3Vlcfkz9UxdLaQJOoVIST996FJ6Ak+bxLC Ex73s/lZeOruTg==; Received: from [2a01:cb18:832e:5f00:3563:417e:2a38:86d8] (port=49154 helo=meije) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzQbM-00036T-2H; Mon, 20 Dec 2021 16:53:49 -0500 From: Mathieu Othacehe To: Ricardo Wurmus Subject: Re: Disk performance on ci.guix.gnu.org References: <875yrjpi1y.fsf@elephly.net> <87o85bjjpm.fsf@gnu.org> <871r27p5jq.fsf@elephly.net> Date: Mon, 20 Dec 2021 22:53:45 +0100 In-Reply-To: <871r27p5jq.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 20 Dec 2021 18:05:08 +0100") Message-ID: <87a6gv3pue.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51787 Cc: 51787@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hey, > Do you mean time the copy or time the removal from that storage? You > know what, I=E2=80=99ll time both. I=E2=80=99ll need to get more space f= irst. I think > the trash directory is larger than the 500G that I got for testing the > SAN. Yeah I meant removal time :) I found this article[1] that suggests that over time the ext4 fragmentation can cause a performance drop that is very noticeable on hard drives. I'm trying to determine how fragmented is the sdb1 file-system, by running e4defrag and e2freefrag[2], but I'm not sure if they will complete soon. Copying and removing /gnu/store/trash on the SAN will be interesting but the ultimate test would be to be able to re-create the ext4 file-system directly on Berlin's sdb drive to evaluate the fragmentation role in this funny business. Thanks, Mathieu [1]: https://www.usenix.org/system/files/hotstorage19-paper-conway.pdf [2]: https://cromwell-intl.com/open-source/performance-tuning/file-systems.= html