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 (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AD87315ACFB for ; Wed, 19 Apr 2023 20:00:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1A74E094E; Wed, 19 Apr 2023 20:00:47 +0000 (UTC) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 6036EE0936 for ; Wed, 19 Apr 2023 20:00:47 +0000 (UTC) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4eed6ddcae1so511568e87.0 for ; Wed, 19 Apr 2023 13:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681934445; x=1684526445; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=GUFvTLxNKbocKDeARWQyd9zG/Alyz21YVE0f/3OcS2g=; b=rBzfnB1ESVcvCvPC3DYfUXUfxeqA9N2YVNuxRO4qiOULDZi3Ss0XSuawK33acdCmkQ DoI73kcW4J9Ug4fZsKxADCyLBjl6ocUgUbOEfHCN7v71trQWAK6pcay9GuvrLSYHhtV4 7b6FqR/1NTZEhytNr7crvYa3En7jqQtlwVQor01EI64z09dvJRkzsmcALkOaEqpBrEQh OM2b5I39KQPuND9OcOWfX8oYn/Crun7b2z1OjUiY9HH4ZVKVziZe1LIMaXggFO8HPfzk W96wd2Bnz0Wo6GDjUjcohv/PrNrAZgnEKe/CKKMZP3Zxg0qaKXytHoYOTG3QoIwpmvWG L8ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681934445; x=1684526445; h=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=GUFvTLxNKbocKDeARWQyd9zG/Alyz21YVE0f/3OcS2g=; b=HJWWtZp1tup9145seIIcAvaB45jGYQxxJ6TbsczmjS53S+Zy89U1XIeqR2TV8Ylhhc +sF8s5c8fM3cyQWgk8nM4x87ph063qEIwTNbwtRvp9/gZYBaAIF2+pIG5iuBxR7R98Bs CU1WNHq8GZI1YyB320qg+iCLizIbAezkdlgNZjActxhTTZjr5pgw8KfGQo6ga3nExnbZ c3DeiSdseEyO41VCPPW4sTrWeuGyNYh/aLu+5yh/Ra+jz+oCxeZrJ/PnbViy+sfpcHq5 4EnpPbuD0ZF45iiEbBWlD5fTSeXynvP2NVY0SGePdjeUdDN+rZQtoTvqR61cMG/OVC+1 4kkw== X-Gm-Message-State: AAQBX9eIARnvvMfwe1NHLxLD+kD1z6rkUlXU6vKUv+7FbnyFBZKx3MV6 Gdm2s/NVdQG2IlsUiDxosDRrJkYBVFuNW/ICv6mP4QDqYzg= X-Google-Smtp-Source: AKy350ZFvsa7hH7QRSwPIx6f2/5eXqr8lS0FfcTQt8cqHAehqhSEgFeuPWaGwRH9XhgR2/V68xigbDd0Q9YllZVQ8wE= X-Received: by 2002:a05:6512:b8c:b0:4d8:86c2:75ea with SMTP id b12-20020a0565120b8c00b004d886c275eamr1500817lfv.3.1681934445308; Wed, 19 Apr 2023 13:00:45 -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: <3a8a143d-38f0-b7ea-4aa1-10c0b3a2a1e0@gmail.com> <81fde7b8-cc55-fcae-79ea-4dd2a78eb8a0@gmail.com> <2703063.mvXUDI8C0e@wstn> <7ef36857-192e-6d2c-dc44-a2c4ba772205@gmail.com> <35474652-f973-75b2-b8e7-4d22915672ac@gmail.com> In-Reply-To: From: Mark Knecht Date: Wed, 19 Apr 2023 13:00:33 -0700 Message-ID: Subject: Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary="00000000000025f0c805f9b5e1de" X-Archives-Salt: 90ca12c6-2639-4aec-9ba2-a24d98e00476 X-Archives-Hash: c81fcfba4473da9f4d465b060cee5a0c --00000000000025f0c805f9b5e1de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 19, 2023 at 12:39=E2=80=AFPM Nikos Chantziaras wrote: > > On 19/04/2023 22:26, Dale wrote: > > So for future reference, let it format with the default? I'm also > > curious if when it creates the file system it will notice this and > > adjust automatically. It might. Maybe? > > AFAIK, SSDs will internally convert to 4096 in their firmware even if > they report a physical sector size of 512 through SMART. Just a > compatibility thing. So formatting with 4096 is fine and gets rid of the > internal conversion. I suspect this is right, or has been mostly right in the past. I think technically they default to the physical block size internally and the earlier ones, attempting to be more compatible with HDDs, had 4K blocks. Some of the newer chips now have 16K blocks but still support 512B Logical Block Addressing. All of these devices are essentially small computers. They have internal controllers, DRAM caches usually in the 1-2GB sort of range but getting larger. The bus speeds they quote is because data is moving for the most part in and out of cache in the drive. In Dale's case, if he has a 4K file system block size then it's going to send 4K to the drive and the drive will write 8 512 byte writes to put it in flash. If I have the same 4K file system block size I send 4K to the drive but my physical block size is 4K so it's a single write cycle to get it into flash. What I *think* is true is that any time your file system block size is smaller than the physical block size on the storage element then simplistically you have the risk of write amplification. What I know I'm not sure about is how inodes factor into this. For instance: mark@science2:~$ ls -i 35790149 000_NOT_BACKED_UP 33320794 All_Files.txt 33337840 All_Sizes_2.txt 33337952 All_Sizes.txt 33329818 All_Sorted.txt 33306743 ardour_deps_install.sh 33309917 ardour_deps_remove.sh 33557560 Arena_Chess 33423859 Astro_Data 33560973 Astronomy 33423886 Astro_science 33307443 'Backup codes - Login.gov.pdf' 33329080 basic-install.sh 33558634 bin 33561132 biosim4_functions.txt 33316157 Boot_Config.txt 33560975 Builder 33338822 CFL_88_F_Bright_Syn.xsc If the inodes are on the disk then how are they stored? Does a single inode occupy a physical block? A 512 byte LBA? Something else? I have no clue. > > I believe Windows always uses 4096 by default and thus it's reasonable > to assume that most SSDs are aware of that. > --00000000000025f0c805f9b5e1de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 19, 2023 at 12:39=E2=80=AFPM Nikos Cha= ntziaras <realnc@gmail.com> w= rote:
>
> On 19/04/2023 22:26, Dale wrote:
> > So for = future reference, let it format with the default?=C2=A0 I'm also
>= ; > curious if when it creates the file system it will notice this and> > adjust automatically. It might.=C2=A0 Maybe?
>
> AF= AIK, SSDs will internally convert to 4096 in their firmware even if
>= they report a physical sector size of 512 through SMART. Just a
> co= mpatibility thing. So formatting with 4096 is fine and gets rid of the
&= gt; internal conversion.

I suspect this is right, or has= been mostly right in the past.=C2=A0

I think tech= nically they default to the physical block size internally
and th= e earlier ones, attempting to be more compatible with HDDs,
had 4= K blocks. Some of the newer chips now have 16K blocks but
still s= upport 512B Logical Block Addressing.=C2=A0

Al= l of these devices are essentially small computers. They have internal=C2= =A0
controllers, DRAM caches usually in the 1-2GB sort of range b= ut getting
larger. The bus speeds they quote is because data is m= oving for the most
part in and out of cache in the drive.=C2=A0

In Dale's case, if he has a 4K file system bloc= k size then it's going to send=C2=A0
4K to the drive and the = drive will write 8 512 byte writes to put it in flash.

=
If I have the same 4K file system block size I send 4K to the drive bu= t
my physical block size is 4K so it's a single write cycle t= o get it=C2=A0
into flash.

What I *think= * is true is that any time your file system block size is
smaller= than the physical block size on the storage element then
simplis= tically you have the risk of write amplification.

What= I know I'm not sure about is how inodes factor into this.

For = instance:

mark@science2:~$ ls -i
35790149 =C2=A0000_NOT_BACKED_UP=
33320794 =C2=A0All_Files.txt
33337840 =C2=A0All_Sizes_2.txt
33337= 952 =C2=A0All_Sizes.txt
33329818 =C2=A0All_Sorted.txt
33306743 =C2=A0= ardour_deps_install.sh
33309917 =C2=A0ardour_deps_remove.sh
33557560 = =C2=A0Arena_Chess
33423859 =C2=A0Astro_Data
33560973 =C2=A0Astronomy<= br>33423886 =C2=A0Astro_science
33307443 'Backup codes - Login.gov.p= df'
33329080 =C2=A0basic-install.sh
33558634 =C2=A0bin
3356113= 2 =C2=A0biosim4_functions.txt
33316157 =C2=A0Boot_Config.txt
33560975= =C2=A0Builder
33338822 =C2=A0CFL_88_F_Bright_Syn.xsc

If the inod= es are on the disk then how are they
stored? Does a single inode occupy= a physical
block? A 512 byte LBA? Something else?

I have no clue= .

>
<= /div>
> I believe Windows always uses 4096 by default and thus it= 9;s reasonable
> to assume that most SSDs are aware of that.
><= br>
--00000000000025f0c805f9b5e1de--