From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 21 12:36:43 2021 Received: (at 51787) by debbugs.gnu.org; 21 Dec 2021 17:36:43 +0000 Received: from localhost ([127.0.0.1]:55472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzj46-0005ig-Pu for submit@debbugs.gnu.org; Tue, 21 Dec 2021 12:36:43 -0500 Received: from sender3-of-o51.zoho.com ([136.143.184.51]:21738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzj45-0005iU-Ii for 51787@debbugs.gnu.org; Tue, 21 Dec 2021 12:36:42 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1640108191; cv=none; d=zohomail.com; s=zohoarc; b=JDqgyzsAypaq9CMTlFtILwmZ30LLNHb20sJHGPab7Qpu8Lm2oJGc1P6t4XAQD8XieoJQz5IbvAJ4ra9mbRWHlfLAc17K0yX/zdZ3E7vLIT3s8/FEATEhU0L8SLuWA0sS5yFP5TiZ0yzsB8B9rK9u0K/mT77OWw9MqsJzvo1NXa4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1640108191; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=jH1Dkp4lD2bICXPSZf+fwlKJ828YTBcl8g3NEzCp1q0=; b=jgubDGrk5DkNle81PDiUxbQWfJIlvJltupTNvAmnlkQgFsokvBECnmfHStkhdInNuVuwGahATwHwKXyDzPx1qcoRYcUX5Gy/AUFelDAr4brQlWL0hSg/yRiF+HKaCIlF1CFqlD2Ks+k5OL8wxb9eYIaeiL/IXZ9Z+0NCeCIv/3o= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1640108191; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:Date:In-reply-to:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=jH1Dkp4lD2bICXPSZf+fwlKJ828YTBcl8g3NEzCp1q0=; b=B+2PHfRBTtb7URbYVoHkYqVeXfSCxvGJp1UKt7NnuF2OPkf8lUsghJMJ20LWuHRk KawcQHxr8i0me0yjKWZLU8IwP4XKCQoLTvwS9ZZVXWAAjr3loVYejWlLsXK5P5OEIcs m0BWehO2IRsSIoZ5aYm3+4cs3pjqtNR+hgnlfKOE= Received: from localhost (p54ad4c64.dip0.t-ipconnect.de [84.173.76.100]) by mx.zohomail.com with SMTPS id 1640108187448384.47795051636797; Tue, 21 Dec 2021 09:36:27 -0800 (PST) References: <875yrjpi1y.fsf@elephly.net> <87o85bjjpm.fsf@gnu.org> <871r27p5jq.fsf@elephly.net> <87a6gv3pue.fsf@gnu.org> User-agent: mu4e 1.6.10; emacs 27.2 From: Ricardo Wurmus To: Mathieu Othacehe Subject: Re: Disk performance on ci.guix.gnu.org Date: Tue, 21 Dec 2021 18:26:03 +0100 In-reply-to: <87a6gv3pue.fsf@gnu.org> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Message-ID: <87v8zhn9m1.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: -0.0 (/) 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: -1.0 (-) Today we discovered a few more things and discussed them on IRC. Here=E2= =80=99s a summary. /var/cache sits on the same storage as /gnu. We mounted the 5TB ext4 file system that=E2=80=99s hosted by the SAN at /mnt_test and started copyi= ng over /var/cache to /mnt_test/var/cache. Transfer speed was considerably faster (not *great*, but reasonably fast) than the copy of /gnu/store/trash to the same target. This confirmed our suspicions that the problem is not with the storage array but due to the fact that /gnu/store/trash (and also /gnu/store) is an extremely large, flat directory. /var/cache is not. Here=E2=80=99s what we do now: continue copying /var/cache to the SAN, then remount to serve substitutes from there. This removes some pressure from the file system as it will only be used for /gnu. We=E2=80=99re considering to dump the file system completely (i.e. reinstall the server), thereby emptying /gnu, but leaving the stash of built substitutes in /var/cache (hosted from the faster SAN). We could take this opportunity to reformat /gnu with btrfs, which performs quite a bit more poorly than ext4 but would be immune to defragmentation. It=E2=80=99s not clear that defragmentation matters here.= It could just be that the problem is exclusively caused by having these incredibly large, flat /gnu/store, /gnu/store/.links, and /gnu/store/trash directories. A possible alternative for this file system might also be XFS, which performs well when presented with unreasonably large directories. It may be a good idea to come up with realistic test scenarios that we could test with each of these three file systems at scale. Any ideas? --=20 Ricardo