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 2B2B0158042 for ; Sat, 16 Nov 2024 14:36:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 842D2E087B; Sat, 16 Nov 2024 14:36:20 +0000 (UTC) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (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 4832EE086F for ; Sat, 16 Nov 2024 14:36:20 +0000 (UTC) Received: by mail-il1-f174.google.com with SMTP id e9e14a558f8ab-3a3b463e9b0so10562315ab.3 for ; Sat, 16 Nov 2024 06:36:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731767774; x=1732372574; 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=l2yO/CAizbFXpVauBh6fHX6ePR0wrSkfqOUuBKepMHo=; b=LtXkx5LvbEjeEeN5VnAcc66Uxptc01wfDgvOdXJteXOZXsF3cs3HRgTw0IS72a0r1S bDL1LtJ+Oajh6anOIgE4c/zSc5V0kBMeN0la/bATCgBXuLv8YyRzV7ZwilzOh4f7c8/j 8Kyk7EMmwdbNtdjMS+4RK5Xga8UCHjqtcOGI7KBRCr6UEMUdD+vbuLwnUSyATWdlvvx1 Z6YeWTJ3E0l1EDHukYkGEBOrW4IE5NQrzcukS2+Gn/OFSxBHZk23iz0mmlxasye9qyJy DRaLnpmtkUO306uNErPLHdFfad8swTibiVv3xQVvAG+9X6iHt9rGc4bZY2ljYUavnGpd rk2Q== X-Gm-Message-State: AOJu0YxgbpNsFU3apHIGN2AP8jqIvkw4GJclYXr1b/2kPj6I9WSFSAf7 F4HVrZNdhdTTuSQtrKN2cFbZOJM7Nl/ANJdam9+cir2+G8bTvz/2xrnZBd7GIABdze4sTSky074 MUbcu8qST8soNW+iyYIotuDhJC+nkJsTR X-Google-Smtp-Source: AGHT+IEYB0x2/0us6tXhsscJzpoNyntRwoCvJqvHJA0CQQSyevr6z5+XCeK4kFmToCeIR/giK/M5Ih0A0t1cvysjdnE= X-Received: by 2002:a05:6e02:b21:b0:3a6:c716:ab1f with SMTP id e9e14a558f8ab-3a74801e64fmr56333155ab.9.1731767773003; Sat, 16 Nov 2024 06:36:13 -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: <115451235.nniJfEyVGO@rogueboard> <2633393.Lt9SDvczpP@rogueboard> In-Reply-To: <2633393.Lt9SDvczpP@rogueboard> From: Rich Freeman Date: Sat, 16 Nov 2024 09:36:02 -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: cb239d52-8b5e-4979-8fc5-52a1d3485a35 X-Archives-Hash: aaf55dd797661afca4265fd9358f6f48 On Sat, Nov 16, 2024 at 6:02=E2=80=AFAM Michael = wrote: > > I assume (simplistically) with DM-SMRs the > discard-garbage collection is managed wholly by the onboard drive control= ler, > while with HM-SMRs the OS will signal the drive to start trimming when th= e > workload is low in order to distribute the timing overheads to the system= 's > idle time. I'll admit I haven't looked into the details as I have no need for SMR and there aren't any good FOSS solutions for using it that I'm aware of (just a few that might be slightly less terrible). However, this doesn't seem correct for two reasons: First, I'm not sure why HM-SMR would even need a discard function. The discard command is used to tell a drive that a block is safe to overwrite without preservation. A host-managed SMR drive doesn't need to know what data is disposable and what data is not. It simply needs to write data when the host instructs it to do so, destroying other data in the process, and it is the host's job to not destroy anything it cares about. If a write requires a prior read, then the host needs to first do the read, then adjust the written data appropriately so that nothing is lost. Second, there is no reason that any drive of any kind (SMR or SSD) NEEDS to do discard/trim operations when the drive is idle, because discard/trim is entirely a metadata operation that doesn't require IO with the drive data itself. Now, some drives might CHOOSE to implement it that way, but they don't have to. On an SSD, a discard command does not mean that the drive needs to erase or move any data at all. It just means that if there is a subsequent erase that would impact that block, it isn't necessary to first read the data and re-write it afterwards. A discard could be implemented entirely in non-volatile metadata storage, such as with a bitmap. For a DM-SMR using flash for this purpose would make a lot of sense - you wouldn't need much of it. This is probably why you have endless arguing online about whether discard/trim is helpful for SSDs. It completely depends on how the drive implements the command. The drives I've owned can discard blocks without any impact on IO, but I've heard some have a terrible impact on IO. It is just like how you can complete the same sort operation in seconds or hours depending on how dumb your sorting algorithm is. In any case, to really take advantage of SMR the OS needs to understand exactly how to structure its writes so as to not take a penalty, and that requires information about the implementation of the storage that isn't visible in a DM-SMR. Sure, some designs will do better on SMR even without this information, but I don't think they'll ever be all that efficient. It is no different from putting f2fs on a flash drive with a brain-dead discard implementation - even if the OS does all its discards in nice consolidated contiguous operations it doesn't mean that the drive will handle that in milliseconds instead of just blocking all IO for an hour - sure, the drive COULD do the operation quickly, but that doesn't mean that the firmware designers didn't just ignore the simplest use case in favor of just optimizing around the assumption that NTFS is the only filesystem in the world. --=20 Rich