Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #93250
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Newsgroups | comp.os.linux.misc |
| Subject | Re: Linux needs less fragmentation |
| Date | 2026-10-09 20:47 +0200 |
| Message-ID | <nisr6hF6jjnU2@mid.individual.net> (permalink) |
| References | (7 earlier) <cpWdneUfD_vF0173nZ2dnZfqn_udnZ2d@giganews.com> <119vn39$mtek$13@dont-email.me> <nii4iaFhu1lU1@mid.individual.net> <11a0r44$179lq$3@dont-email.me> <nipnemFmrjqU1@mid.individual.net> |
On 2026-10-08 16:25, Andy Burns wrote:
> The Natural Philosopher wrote:
>
>> SD caches a block when reading.
>>
>> And IIRC a larger page when writing
>>
>> Erase blocks are even larger
>>
>> IN all cases response shows no 'seek' delays.
>>
>> Writes are fully cached and written behind in SSD time. The
>> application has no control, over that.
>>
>> Ultimately Linux cacheing is probably completely irrelevant.
> By themselves, SSDs have no concept of which blocks are in-use by the
> host's filesystem, use of TRIM commands allow O/S to tell the internal
> controller to mark unused blocks for coalescing into larger blocks for
> erasing.
>
> So no they don't care in terms of seek times, or needing traditional
> defragging, but they do care in terms of avoiding extra writes during
> garbage collection (blocks can't be overwritten, only re-written within
> those larger erased blocks).
>
I asked chatgpt (as a glorified documentation search engine):
Q: Have SSD disks an internal RAM cache, and what is it used for? I'm interested in normal read operations.
A: Yes. Many SSDs have internal RAM, but it is important to distinguish between RAM used for managing the SSD and RAM used to cache data. For normal read operations, the distinction matters quite a bit.
1. What memory does an SSD have?
1.1. DRAM cache
Some SSDs have a dedicated DRAM chip, typically hundreds of megabytes to several gigabytes in larger drives. It is volatile memory, just like your computer's RAM.
It is primarily used to store the SSD's internal mapping tables, which translate logical block addresses into physical NAND flash locations.
1.2. NAND flash memory
This is the actual nonvolatile storage where your files and data reside. Some SSDs also use portions of their NAND as a cache for writes, but that is a different function from DRAM.
1.3. Controller SRAM
The SSD controller itself typically has a small amount of fast SRAM. It holds temporary data, commands, and metadata while the controller processes requests. This is much smaller than a typical DRAM cache.
Not every SSD has dedicated DRAM. Many budget SSDs are DRAM-less and rely on the controller's internal memory and, in some NVMe designs, the computer's RAM through a feature called Host Memory Buffer (HMB).
2. What happens during a normal read?
Suppose your operating system requests 4 KB from a particular logical address on the SSD.
Operating system / application
Requests a logical block
↓
SSD controller
Looks up the logical-to-physical address mapping
↓
NAND flash
Reads the requested data from flash cells
↑
Data returned to the computer
The DRAM cache is useful mainly in the middle step. It can hold the mapping table so that the controller can quickly find where the requested data lives.
Without DRAM, the controller may need to retrieve mapping information from NAND itself, which can add latency. The exact impact depends on the SSD's design and workload.
3. Does the SSD cache the actual data being read?
It can, but this is not generally the main purpose of an SSD's DRAM.
There are three important cases:
Situation What happens
----------- ---------------
First read of a block The SSD normally fetches the data from NAND flash.
Repeated read of the same block It may be served from a controller buffer if the SSD has retained that data, but this is not guaranteed.
Repeated read of a file by
an application The operating system may serve the data from its own RAM cache, without accessing the SSD at all.
The third case is particularly important. Your computer's operating system typically uses otherwise available RAM to cache recently accessed file data. That cache can be much larger than the SSD's internal RAM.
Also, an SSD may perform internal read-ahead or buffer data temporarily, but its controller does not necessarily retain previously read user data for long-term caching.
4. How much does internal RAM improve read performance?
It depends on the workload.
* Random reads: DRAM can help by making address translation faster, especially when the mapping information would otherwise require extra flash accesses.
* Sequential reads: The SSD can usually read efficiently from NAND in either case. DRAM may help with mapping and request management, but it is not necessarily the main performance bottleneck.
* Repeated reads: The operating system's RAM cache often has a much larger effect than the SSD's internal DRAM.
* Large working sets with random access: A DRAM-equipped SSD can have an advantage, particularly when its mapping tables are large and cannot be held entirely in the controller's small internal memory.
A DRAM-less SSD can still deliver excellent read performance. Modern controllers and HMB can reduce the performance gap substantially for some workloads.
The key takeaway
If you're interested specifically in normal reads, an SSD's internal DRAM is primarily an address-translation cache, not a general-purpose cache of recently read file contents. The NAND flash holds the actual data, while the computer's own RAM is usually the more significant cache for repeated file reads.
One final distinction: a write cache can improve write speed by temporarily accepting data before it is fully committed to NAND. That is a separate issue from the read behavior discussed here.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺.
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Linux needs less fragmentation Lars Poulsen <lars@beagle-ears.com> - 2026-10-04 14:08 -0700
Re: Linux needs less fragmentation Michael Logies <logies@t-online.de> - 2026-10-04 23:33 +0200
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-05 09:20 +0100
Re: Linux needs less fragmentation Leroy H <lh@somewhere.net> - 2026-10-04 21:44 +0000
Re: Linux needs less fragmentation rbowman <bowman@montana.com> - 2026-10-05 01:53 +0000
Re: Linux needs less fragmentation c186282 <c186282@nnada.net> - 2026-10-05 03:14 -0400
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-05 09:28 +0100
Re: Linux needs less fragmentation "Carlos E. R." <robin_listas@es.invalid> - 2026-10-05 19:20 +0200
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-05 19:43 +0100
Re: Linux needs less fragmentation Andy Burns <usenet@andyburns.uk> - 2026-10-08 15:25 +0100
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-08 15:29 +0100
Re: Linux offers choice, BSD offers fragmentation Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-08 20:59 +0000
Re: Linux needs less fragmentation c186282 <c186282@nnada.net> - 2026-10-09 02:42 -0400
Re: Linux needs less fragmentation "Carlos E. R." <robin_listas@es.invalid> - 2026-10-09 20:47 +0200
Re: Linux offers choice, BSD offers fragmentation Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-09 21:20 +0000
Re: Linux offers choice, BSD offers fragmentation "Carlos E. R." <robin_listas@es.invalid> - 2026-10-09 23:27 +0200
Re: Linux offers choice, BSD offers fragmentation c186282 <c186282@nnada.net> - 2026-10-10 04:01 -0400
Re: Linux offers choice, BSD offers fragmentation c186282 <c186282@nnada.net> - 2026-10-11 04:31 -0400
Re: Linux needs less fragmentation Rich <rich@example.invalid> - 2026-10-05 18:57 +0000
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-05 20:08 +0100
Re: Linux needs less fragmentation Rich <rich@example.invalid> - 2026-10-05 20:18 +0000
Re: Linux needs less fragmentation Richard Kettlewell <invalid@invalid.invalid> - 2026-10-06 08:34 +0100
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-06 11:17 +0100
Re: Linux needs less fragmentation c186282 <c186282@nnada.net> - 2026-10-06 23:59 -0400
Re: Linux needs less fragmentation rbowman <bowman@montana.com> - 2026-10-06 14:39 +0000
Re: Linux needs less fragmentation Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-10-06 13:50 -0400
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-05 09:25 +0100
Re: Linux needs less fragmentation rbowman <bowman@montana.com> - 2026-10-05 19:36 +0000
Re: Linux needs less fragmentation "Carlos E. R." <robin_listas@es.invalid> - 2026-10-05 21:49 +0200
Re: Linux needs less fragmentation rbowman <bowman@montana.com> - 2026-10-06 02:35 +0000
Re: Linux needs less fragmentation Philippe <p.naudin+nntp@free.fr> - 2026-10-06 08:13 +0200
Re: Linux needs less fragmentation "Carlos E. R." <robin_listas@es.invalid> - 2026-10-06 11:12 +0200
Re: Linux needs less fragmentation rbowman <bowman@montana.com> - 2026-10-06 14:48 +0000
Re: Linux needs less fragmentation The Natural Philosopher <tnp@invalid.invalid> - 2026-10-05 09:19 +0100
csiph-web