From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-199509-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 515E6158094
for <garchives@archives.gentoo.org>; Mon, 22 Aug 2022 15:03:20 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6C758E0948;
Mon, 22 Aug 2022 15:03:02 +0000 (UTC)
Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id AF0A6E0935
for <gentoo-user@lists.gentoo.org>; Mon, 22 Aug 2022 15:03:01 +0000 (UTC)
Received: by mail-pf1-f171.google.com with SMTP id y15so6618809pfr.9
for <gentoo-user@lists.gentoo.org>; Mon, 22 Aug 2022 08:03:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc;
bh=W1S0PeMR70FQGmZM90NaKE4dcstNDSNiNCDVzDJ4e/0=;
b=JZ/hst/y6jTOyUYFf1xutNG6I/oZglLM6v9v920G6OO+jo9pOBe4AJhs6qmPISUI+m
/P2/xmGWvL7xZ9YMyZ1R4a+XiuR+Rah2P9yJoaR2IVmb7Smrdujw9lKnaHjq5unnpTsx
bWSs6WC7lz2oNE8kgUKD8UQ03XQXZkChOiane1XrfnzC8qDgXxxYiIeR+36zhbdmq3Ow
gRJisnWovVqmQphbtP9TTQNU9p9HlQ8FDvT1Ed2O0WMTl8IhmoS7smob+xLzyw22fMCG
1mQ+3dCLHLJSEB1yB281EksDvFc9EvFOAUiQ92b4WPeVOimDChf6iwn+aV91H1rzlWb/
OZ7A==
X-Gm-Message-State: ACgBeo3pLkuojg6fNbyG5J2JiaN3ciosZfllQAWsuV4IebstHF38m94h
MnobYBvexu+ovcBSdnz8D3Mdi2/3nAZ4qocsabw3vaV0h5I=
X-Google-Smtp-Source: AA6agR7PEZ8VZPFkFYnafbKSjsrORAv4d91K6wH/s+c2ESqzMFJ3ohT62Ui+QgbPBwtGxx2nPSVLCXkQTm5ctzmkx/Q=
X-Received: by 2002:a63:6344:0:b0:42a:498d:2b1e with SMTP id
x65-20020a636344000000b0042a498d2b1emr12823924pgb.618.1661180580033; Mon, 22
Aug 2022 08:03:00 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <b918b55b-80c0-40be-975c-825a8586da8f@gmail.com>
<a30d83e3-5b6e-a6d9-2283-43819c4604f2@gmail.com> <ed694361-f411-8062-b033-d4bae176868b@spamtrap.tnetconsulting.net>
<MW2PR07MB405850C442698D47B640730FD2719@MW2PR07MB4058.namprd07.prod.outlook.com>
In-Reply-To: <MW2PR07MB405850C442698D47B640730FD2719@MW2PR07MB4058.namprd07.prod.outlook.com>
From: Rich Freeman <rich0@gentoo.org>
Date: Mon, 22 Aug 2022 11:02:48 -0400
Message-ID: <CAGfcS_mA7PZRjYMO2hm7kyyG9zuKdMCLR2VnZbn250p1ks_77Q@mail.gmail.com>
Subject: Re: [gentoo-user] Getting maximum space out of a hard drive
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 599d82e7-d614-413e-9fd1-23ee5ea3ff4d
X-Archives-Hash: b0b43ee641d8e30d99bffb89182131be
On Mon, Aug 22, 2022 at 10:50 AM Laurence Perkins <lperkins@openeye.net> wr=
ote:
>
> Note that 60ish MB/sec is very reasonable for a rotational drive. They *=
can* technically go faster, but only if you keep the workload almost entire=
ly sequential. Most filesystems require a fair amount of seeking to write =
metadata, which slows them down quite a bit.
>
> If you're desperate for performance, you can do things like tell it to ig=
nore write barriers and turn off various bits of flushing and increase the =
amount of allowed dirty write cache. These can be good for a significant p=
erformance boost at the cost of almost certainly corrupting the filesystem =
if the system loses power or crashes.
>
I've also found that on large drives the sequential write speed varies
based on position in the drive. If I run something like badblocks on
a new hard drive I'll see it start out at something like 200MB/s, and
by the end it is around100MB/s. Then at the start of the next pass it
will jump back up to 200MB/s. This is just direct block-level
sequential writes so it is an ideal use case.
As you say, ANY seeking will dramatically reduce the throughput. Time
spent seeking is time not spent writing. There is no opportunity to
"catch up" as the drive's read/write bandwidth is basically just a
function of the recording density and rotational rate and number of
platters/etc being read in parallel. If it is seeking it is a lost
opportunity to read/write.
--=20
Rich