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