From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F0D0A158086 for ; Wed, 6 Oct 2021 16:47:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CE035E09A5; Wed, 6 Oct 2021 16:47:34 +0000 (UTC) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 70942E099C for ; Wed, 6 Oct 2021 16:47:34 +0000 (UTC) Received: by mail-ot1-f51.google.com with SMTP id h16-20020a9d3e50000000b0054e25708f41so3088622otg.0 for ; Wed, 06 Oct 2021 09:47:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=2JBthnFNnbwfXfnyyx0W1TGFXhwEMyAgkZqYy3zeNfo=; b=WHKPvGUzZ6smLs0A90tTxTWLiFOx3cdTlSd+ICs46h0WslPkhj7YW91sgRJz86RBog +CbXzsN//WQqd+DcTptAJ2s4uSAdT+8v0tyL87nb0Z3T5M88Oega+MjP60yOS8EgX75b eg1rBPZUrekhdULbFQ9hlDhjWELfChRRc4T9/APq0uniA6FymiAMKRmPz3CIX9HWW7ml QFx3KqoCo8r9ooZp0oB2m1YbMVOsOC/98R/GGEtZhmsDNzo0Tu3chiAGo9jQSZzF1qDB 7sEdXJg4ZUqBejwxdSWemSM4cThVKJL9zq3MyRW8l6mtnRE4D8coJX2XnOdbZA2Z4e1x UU5A== X-Gm-Message-State: AOAM533rcXDR4XYSf6GFx1Qrvmn1mbCvLNwvHjC9AfG8y8B5VCDOfxRC fTKM1147Zsb69n7WLu1KiKg/7ezPCmE1WRBgmuCm9MWQ X-Google-Smtp-Source: ABdhPJyGrNWR0HJngwcgLuooJszz7wZJTCaIavLCPTV3fpWJ7a/q6UVJM3Dbuk5Iqvhc2SmRBSsdNIQkb3vj2F6W16A= X-Received: by 2002:a9d:7256:: with SMTP id a22mr20858265otk.336.1633538852227; Wed, 06 Oct 2021 09:47:32 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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: <3e528088-4325-202d-cd1f-f29efb42638d@gmail.com> In-Reply-To: From: Rich Freeman Date: Wed, 6 Oct 2021 12:47:22 -0400 Message-ID: Subject: Re: [gentoo-user] Hard drive pricing and the near future To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 6c31c636-b526-4edc-8738-2c7249392137 X-Archives-Hash: 866aed90239cb77d7d24b662d38e6cff On Wed, Oct 6, 2021 at 12:16 PM Laurence Perkins wro= te: > > Other option, depending on exactly what your use case is would be to look= into your choice of filesystem. SMR doesn't like random writes into one o= f its chunks unless it has enough idle time to go back and straighten it ou= t later is all. There are now format options for ext4 to align its metadat= a to the SMR sections and to make it avoid random writes as much as it can.= Additionally BTRFS, ZFS, and NILFS2 are all structured such that they ten= d to write from one end of the disk to the other and then jump back to the = beginning, so they see little if any degradation from SMR. Unless something has changed, it was ZFS rebuilds that caused a lot of the initial fuss on Linux. Drives were getting dropped from pools due to timeouts/etc during rebuilds. I'm not sure how sequential the IO is for ZFS rebuilds. I think btrfs seems a bit smarter about scrubs in general. --=20 Rich