From: Mark Knecht <markknecht@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on
Date: Wed, 19 Apr 2023 13:00:33 -0700 [thread overview]
Message-ID: <CAK2H+eexeFK3J6CmXWZhLgwsnZxPHKNbV_aD8=0waPGHEy2d7w@mail.gmail.com> (raw)
In-Reply-To: <u1pg0d$uk8$1@ciao.gmane.io>
[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]
On Wed, Apr 19, 2023 at 12:39 PM Nikos Chantziaras <realnc@gmail.com> 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.
>
[-- Attachment #2: Type: text/html, Size: 3128 bytes --]
next prev parent reply other threads:[~2023-04-19 20:00 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-15 22:47 [gentoo-user] Finally got a SSD drive to put my OS on Dale
2023-04-15 23:24 ` Mark Knecht
2023-04-15 23:44 ` thelma
2023-04-16 1:47 ` William Kenworthy
2023-04-16 7:18 ` Peter Humphrey
2023-04-16 8:43 ` William Kenworthy
2023-04-16 15:08 ` Mark Knecht
2023-04-16 15:29 ` Dale
2023-04-16 16:10 ` Mark Knecht
2023-04-16 16:54 ` Dale
2023-04-16 18:14 ` Mark Knecht
2023-04-16 18:53 ` Dale
2023-04-16 19:30 ` Mark Knecht
2023-04-16 22:26 ` Dale
2023-04-16 23:16 ` Frank Steinmetzger
2023-04-17 1:14 ` Dale
2023-04-17 9:40 ` Wols Lists
2023-04-17 17:45 ` Mark Knecht
2023-04-18 0:35 ` Dale
2023-04-18 8:03 ` Frank Steinmetzger
2023-10-07 7:22 ` Dale
2023-04-16 17:46 ` Jorge Almeida
2023-04-16 18:07 ` Frank Steinmetzger
2023-04-16 20:22 ` Mark Knecht
2023-04-16 22:17 ` Frank Steinmetzger
2023-04-17 0:34 ` Mark Knecht
2023-04-18 14:52 ` [gentoo-user] " Nikos Chantziaras
2023-04-18 15:05 ` Dale
2023-04-18 15:36 ` Nikos Chantziaras
2023-04-18 20:01 ` Dale
2023-04-18 20:53 ` Wol
2023-04-18 22:13 ` Frank Steinmetzger
2023-04-18 23:08 ` Wols Lists
2023-04-19 1:15 ` Dale
2023-04-18 20:57 ` Mark Knecht
2023-04-18 21:15 ` Dale
2023-04-18 21:25 ` Mark Knecht
2023-04-19 1:36 ` Dale
2023-04-18 22:18 ` Frank Steinmetzger
2023-04-18 22:41 ` Frank Steinmetzger
2023-04-19 1:45 ` Dale
2023-04-19 8:00 ` Nikos Chantziaras
2023-04-19 9:42 ` Dale
2023-04-19 10:34 ` Peter Humphrey
2023-04-19 17:14 ` Mark Knecht
2023-04-19 17:59 ` Dale
2023-04-19 18:13 ` Mark Knecht
2023-04-19 19:26 ` Dale
2023-04-19 19:38 ` Nikos Chantziaras
2023-04-19 20:00 ` Mark Knecht [this message]
2023-04-19 22:13 ` Frank Steinmetzger
2023-04-19 23:32 ` Dale
2023-04-20 1:09 ` Mark Knecht
2023-04-20 4:23 ` Dale
2023-04-20 4:41 ` eric
2023-04-20 9:48 ` Dale
2023-04-20 23:02 ` Wol
2023-04-20 8:55 ` Frank Steinmetzger
2023-04-20 8:52 ` Frank Steinmetzger
2023-04-20 9:29 ` Dale
2023-04-20 10:08 ` Peter Humphrey
2023-04-20 10:59 ` Dale
2023-04-20 13:23 ` Nikos Chantziaras
2023-04-20 12:23 ` Frank Steinmetzger
2023-04-20 9:46 ` Peter Humphrey
2023-04-20 9:49 ` Dale
2023-04-18 17:52 ` Mark Knecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK2H+eexeFK3J6CmXWZhLgwsnZxPHKNbV_aD8=0waPGHEy2d7w@mail.gmail.com' \
--to=markknecht@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox