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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F0F27158164 for ; Sun, 17 Nov 2024 21:26:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3052BE0F58; Sun, 17 Nov 2024 21:26:46 +0000 (UTC) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 E3605E0F4E for ; Sun, 17 Nov 2024 21:26:45 +0000 (UTC) Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-83aac75fcceso38820939f.0 for ; Sun, 17 Nov 2024 13:26:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731878805; x=1732483605; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YiUEbptk7us2CtNPaGnBdBu1bFMg31mIK1c1iZ3lKRM=; b=P6q7xdGAF0+vjcrEfEpi7LqNzXY2p6iN1dcpiCjCaRI52CZKfgkvtkYkcm1M2D8Fl3 pHZvBGV6UhVT71GKSv+3kTMY3EqHtxZFlTn3ofnSKRgVab3lp5YhPNP3xEaw1G06o5Mo qzX+0O0F142HaNf5Q0PQHm6T3a2MRRQjnu3p38yHY08MzAqGVe3Gb90pjG+rGik8t+v1 c7LMicH5TnO4bSTmDUKiuH7o9f1tytyp1TY+/YljZ3D+Pe/uk2waBr8AAEXbrNJ0DEim XisDtoNmIs2mdij2YUwV3X/IWdQwryiZQKiPb3h3sC1Hz5KFqhDVD2T43WGhL29R94Jj +Ulw== X-Gm-Message-State: AOJu0Yy9ZI60zRrdmLrXyUvGP8uPx2rrKY7Y7lD8fUOzVIvTiTZk/Kdb +oWvzasBWElUfb50llWxLdWLwdBQ8drZQzhLIHgf3k5ZTvSxDmyUeKH8LTBRYGrylW3PDVE8y31 mscImPq90Nhf1KcCtOGC/UJUE9oyJ+A== X-Google-Smtp-Source: AGHT+IECZFqoLx38emXyQZTydtfCXw4p7tfscpeN6S5kBCNhWFdAKv8zl3hBvohTCCENT2xQT5ShTYBFt3RoxUWeNIg= X-Received: by 2002:a05:6602:3fc1:b0:835:45ed:bc23 with SMTP id ca18e2360f4ac-83e6c0a8208mr1018622639f.3.1731878804600; Sun, 17 Nov 2024 13:26:44 -0800 (PST) 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: <1836185.3VsfAaAtOV@rogueboard> <3598598.iIbC2pHGDl@rogueboard> In-Reply-To: <3598598.iIbC2pHGDl@rogueboard> From: Rich Freeman Date: Sun, 17 Nov 2024 16:26:34 -0500 Message-ID: Subject: Re: [gentoo-user] Seagate hard drives with dual actuators. To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7f18e782-9abb-44b4-98c1-57317c44139e X-Archives-Hash: 4de53a63d72141b19d2bdc849879001b On Sun, Nov 17, 2024 at 6:22=E2=80=AFAM Michael = wrote: > > On Saturday 16 November 2024 20:13:30 GMT Rich Freeman wrote: > > > > The idea of a host-managed drive is to avoid the random writes in the > > first place, and the need to do the random reads. For this to work > > the host has to know where the boundaries of the various regions are > > and where it is safe to begin writes in each region. > > The random reads do not incur a time penalty, it is the R-M-W ops that co= st > time. We're saying the same thing. If you don't preserve data that you overwrite, then there is no need to read anything. Random reads are the same speed on CMR and SMR, but not doing a read is faster than doing a read on either platform, and any read on an HDD is very slow. > The host don't need to know where bands start and finish, only needs to > submit data in whole sequential streams, so they can be written directly = to > the disk as in a CMR. As long as data and metadata are submitted and wri= tten > directly, the SMR would be alike a CMR in terms of its performance. Again, we're saying the same thing, but making different assumptions about how HM-SMR is implemented. SMR can be appended to without penalty, just like tape. In order to append and not overwrite, the host needs to know where the boundaries of the SMR domains are. > I assumed, may be wrongly, there is still an STL function performed by th= e > controller on HM-SMRs, to de-allocate deleted data bands whenever files a= re > deleted, perform secure data deletions via its firmware, etc. However, I= can > see if this is managed at the fs journal layer the drive controller could= be > dumb in this respect. Honestly, I don't know exactly what commands an HM-SMR implements, and since I doubt I'll ever use one, I can't really be bothered to look them up. The whole point of a HM-SMR drive is that the drive just does exactly what the host does, and doesn't try to shield the host from the details of how SMR works. That's why they can be used without performance penalties. They're just very destructive to data if they aren't used correctly. > It would be interesting to see how different fs types perform on DM-SMRs. Not that interesting, for me personally. That's like asking how well different filesystems would perform on tape. If I'm storing data on tape, I'll use an algorithm designed to work on tape, and a tape drive that actually has a command set that doesn't try to pretend that it is useful for random writes. SMR is pretty analogous to tape, with the benefit of being as fast as CMR for random reads. If anything I've been trying to migrate away from HDD entirely. NVMe will always be more expensive I'm sure but the density and endurance are continuing to improve, and of course the speed is incomparable. Cost is only a few times more. Biggest challenge is the lanes but used workstations seem to be a way to get around that. --=20 Rich