From: Frank Steinmetzger <Warp_7@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on
Date: Thu, 20 Apr 2023 00:13:54 +0200 [thread overview]
Message-ID: <ZEBnoszh_TfFL2mV@moby> (raw)
In-Reply-To: <CAK2H+eexeFK3J6CmXWZhLgwsnZxPHKNbV_aD8=0waPGHEy2d7w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]
Am Wed, Apr 19, 2023 at 01:00:33PM -0700 schrieb Mark Knecht:
> 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.
Actually, cheap(er) SSDs don’t have an own DRAM, but rely on the host for
this. There is an ongoing debate in tech forums whether that is a bad thing
or not. A RAM cache can help optimise writes by caching many small writes
and aggregating them into larger blocks.
> The bus speeds they quote is because data is moving for the most
> part in and out of cache in the drive.
Are you talking about the pseudo SLC cache? Because AFAIK the DRAM cache has
no influence on read performance.
> 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?
man mkfs.ext4 says:
[…] the default inode size is 256 bytes for most file systems, except for
small file systems where the inode size will be 128 bytes. […]
And if a file is small enough, it can actually fit inside the inode itself,
saving the expense of another FS sector.
When formatting file systems, I usually lower the number of inodes from the
default value to gain storage space. The default is one inode per 16 kB of
FS size, which gives you 60 million inodes per TB. In practice, even one
million per TB would be overkill in a use case like Dale’s media storage.¹
Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB, not
counting extra control metadata and ext4 redundancies.
The defaults are set in /etc/mke2fs.conf. It also contains some alternative
values of bytes-per-inode for certain usage types. The type largefile
allocates one inode per 1 MB, giving you 1 million inodes per TB of space.
Since ext4 is much more efficient with inodes than ext3, it is even content
with 4 MB per inode (type largefile4), giving you 250 k inodes per TB.
For root partitions, I tend to allocate 1 million inodes, maybe some more
for a full Gentoo-based desktop due to the portage tree’s sheer number of
small files. My Surface Go’s root (Arch linux, KDE and some texlive) uses
500 k right now.
¹ Assuming one inode equals one directory or unfragmented file on ext4.
I’m not sure what the allocation size limit for one inode is, but it is
*very* large. Ext3 had a rather low limit, which is why it was so slow with
big files. But that was one of the big improvements in ext4’s extended
inodes, at the cost of double inode size to house the required metadata.
--
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.
FINE: Tax for doing wrong. TAX: Fine for doing fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-04-19 22:14 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
2023-04-19 22:13 ` Frank Steinmetzger [this message]
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=ZEBnoszh_TfFL2mV@moby \
--to=warp_7@gmx.de \
--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