Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #92873 > unrolled thread

Linux needs less fragmentation

Back to article view | Back to comp.os.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 1 of 2  [1] 2  Next page →

#92873 — Linux needs less fragmentation

On 10/4/2026 02:47, Daniel70 wrote:
> On 3/10/2026 10:01 pm, CrudeSausage wrote:
>> On 2026-10-02 8:23 p.m., Paul wrote:
>>> On Fri, 10/2/2026 1:17 PM, CrudeSausage wrote:
>>>> On 2026-10-02 1:03 p.m., CrudeSausage wrote:
> [...]
> Yeap, for sure .... but the problem (as I see it) is that Linux is
> soooo flexible that everyone modifies the BASE LINUX OS to suit THEIR
> needs (Me, Mageia!! eventually) whereas MicroSoft releases Windows "AND 
> YOU *WILL* USE IT THE WAY *WE* WANT"!!
> 
> If only Linux Devs could get together!! ;-P Pipe Dreams!!
> 
> But thank you Devs!!

A lot of the noise is "Ubuntu based distributions" and "Fedora based 
distributions". In my opinion, those should not be distributions, they 
should be packages to load on top of those mainstream distributions.
In the cases that I am aware of, they are basically tweaks to the GUI to 
suit a particular taste.

Reducing the noise would help newbies understand the field much better.
-- 
Lars Poulsen - an old geek in Santa Barbara, California

[toc] | [next] | [standalone]

#92874

On Sun, 4 Oct 2026 14:08:35 -0700, Lars Poulsen <lars@beagle-ears.com>
wrote:

>Reducing the noise would help newbies understand the field much better.

Linux Mint has consistently ranked at or near the top on DistroWatch
for years. I run the flagship Cinnamon edition, which I consider the
ideal choice for Linux newcomers. Thanks to its Ubuntu foundation and
extensive documentation, an integrated AI agent like Qwen Code can
easily manage the system. I have coupled it with a local memory
system, enabling the agent to retain context and recall past
operations: https://www.logies.de/memory-mcp-for-ai-agents.html

[toc] | [prev] | [next] | [standalone]

#92917

On 04/10/2026 22:33, Michael Logies wrote:
> On Sun, 4 Oct 2026 14:08:35 -0700, Lars Poulsen <lars@beagle-ears.com>
> wrote:
> 
>> Reducing the noise would help newbies understand the field much better.
> 
> Linux Mint has consistently ranked at or near the top on DistroWatch
> for years. I run the flagship Cinnamon edition, which I consider the
> ideal choice for Linux newcomers. Thanks to its Ubuntu foundation and
> extensive documentation, an integrated AI agent like Qwen Code can
> easily manage the system. I have coupled it with a local memory
> system, enabling the agent to retain context and recall past
> operations: https://www.logies.de/memory-mcp-for-ai-agents.html

Amen. I run MATE but that's because I left windows around XP time and I 
never got used to eye candy

-- 
How fortunate for governments that the people they administer don't think.

Adolf Hitler

[toc] | [prev] | [next] | [standalone]

#92875

On Sun, 4 Oct 2026 14:08:35 -0700, Lars Poulsen wrote:

> 
> A lot of the noise is "Ubuntu based distributions" and "Fedora based 
> distributions". In my opinion, those should not be distributions, they 
> should be packages to load on top of those mainstream distributions.
> In the cases that I am aware of, they are basically tweaks to the GUI to 
> suit a particular taste.
> 

What is Linux?

Linux is an OS which means that it provides (configurable) access to
hardware from "user space."  There is nothing more.

The question then becomes "what is user space?" and this is where the
distributions come in.

A distribution provides "user space" for all those who cannot provide
it for themselves.

There can be many, many choices for user space.  Consequently, there
should be many, many different choices for a distribution.

But there are not.  Most distros align with RedHat, Debian, or Arch.

Your assertion about "noise" is false.  The noise is only an illusion.
Beneath it all is total sameness.

GNU/Linux is being highly circumscribed by both the popular distros
and the acquiescence of its users.

[toc] | [prev] | [next] | [standalone]

#92884

On Sun, 4 Oct 2026 14:08:35 -0700, Lars Poulsen wrote:

> A lot of the noise is "Ubuntu based distributions" and "Fedora based
> distributions". In my opinion, those should not be distributions, they
> should be packages to load on top of those mainstream distributions.
> In the cases that I am aware of, they are basically tweaks to the GUI to
> suit a particular taste.

Ubuntu has a few GNOME tweaks that make it more usable than vanilla GNOME. 
KDE on Fedora, Arch, and SUSE are all very similar with little 
customization. MX does a nice job with Xfce, better than Debian or Devuan.

Ubuntu has Lubuntu, Xubuntu, Kubuntu. Mint offers Cinnamon, MATE, and Xfce 
with separate isos for each.  Fedora has 'spins' with GNOME and KDE now as 
mainstream. SUSE includes GNOME, KDE, and Xfce in the offline installer. 
Devuan has those and a couple of more.

What you're overlooking is some of the other differences. Rolling, semi-
rolling, or slow releaes. Snpa, flatpak, or nothing by default? Systemd, 
SysVinit, runit? X11 or Wayland? 

[toc] | [prev] | [next] | [standalone]

#92904

On 10/4/26 21:53, rbowman wrote:
> On Sun, 4 Oct 2026 14:08:35 -0700, Lars Poulsen wrote:
> 
>> A lot of the noise is "Ubuntu based distributions" and "Fedora based
>> distributions". In my opinion, those should not be distributions, they
>> should be packages to load on top of those mainstream distributions.
>> In the cases that I am aware of, they are basically tweaks to the GUI to
>> suit a particular taste.
> 
> Ubuntu has a few GNOME tweaks that make it more usable than vanilla GNOME.
> KDE on Fedora, Arch, and SUSE are all very similar with little
> customization. MX does a nice job with Xfce, better than Debian or Devuan.
> 
> Ubuntu has Lubuntu, Xubuntu, Kubuntu. Mint offers Cinnamon, MATE, and Xfce
> with separate isos for each.  Fedora has 'spins' with GNOME and KDE now as
> mainstream. SUSE includes GNOME, KDE, and Xfce in the offline installer.
> Devuan has those and a couple of more.
> 
> What you're overlooking is some of the other differences. Rolling, semi-
> rolling, or slow releaes. Snpa, flatpak, or nothing by default? Systemd,
> SysVinit, runit? X11 or Wayland?

   MANY choices these days ... a lot better than Winders.

   Linux is "fairly" resistant to disk fragmentation,
   better than Win for the most part. Some of the utils
   can kind-of deal with it. However if things get
   really bad, like on a server drive, in the end you
   have to copy over to a new drive. This is not
   guarenteed to get the boot/efi sectors alas. 'dd'
   is TOO literal, won't fix yer frag.

   Some say that frag is NOT important anymore due to
   e-disks. Sort-of true, sort-of not. In the end you
   will get more and more kinda unusable sectors.

   I still have a few big magnetics ... frag IS important.

[toc] | [prev] | [next] | [standalone]

#92919

On 05/10/2026 08:14, c186282 wrote:
> MANY choices these days ... a lot better than Winders.
> 
>    Linux is "fairly" resistant to disk fragmentation,
>    better than Win for the most part. Some of the utils
>    can kind-of deal with it. However if things get
>    really bad, like on a server drive, in the end you
>    have to copy over to a new drive. This is not
>    guarenteed to get the boot/efi sectors alas. 'dd'
>    is TOO literal, won't fix yer frag.
> 
Never had to in years.
SSDs simply dont care, since a sector seek is no more expensive than 
'next sector'


>    Some say that frag is NOT important anymore due to
>    e-disks. Sort-of true, sort-of not. In the end you
>    will get more and more kinda unusable sectors.
> 
More ignorant bollocks

>    I still have a few big magnetics ... frag IS important.

It would be if you were running multiple parallel tasks, but then you 
would be using RAID anyway and enough RAM to cache a whole Tuesday
-- 
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

[toc] | [prev] | [next] | [standalone]

#92951

On 2026-10-05 10:28, The Natural Philosopher wrote:
> On 05/10/2026 08:14, c186282 wrote:
>> MANY choices these days ... a lot better than Winders.
>>
>>    Linux is "fairly" resistant to disk fragmentation,
>>    better than Win for the most part. Some of the utils
>>    can kind-of deal with it. However if things get
>>    really bad, like on a server drive, in the end you
>>    have to copy over to a new drive. This is not
>>    guarenteed to get the boot/efi sectors alas. 'dd'
>>    is TOO literal, won't fix yer frag.
>>
> Never had to in years.
> SSDs simply dont care, since a sector seek is no more expensive than 
> 'next sector'

True, but next sector might be in the cache. Might, dunno how an SSD 
does internal caching. There is still system caching.



-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#92955

On 05/10/2026 18:20, Carlos E. R. wrote:
> On 2026-10-05 10:28, The Natural Philosopher wrote:
>> On 05/10/2026 08:14, c186282 wrote:
>>> MANY choices these days ... a lot better than Winders.
>>>
>>>    Linux is "fairly" resistant to disk fragmentation,
>>>    better than Win for the most part. Some of the utils
>>>    can kind-of deal with it. However if things get
>>>    really bad, like on a server drive, in the end you
>>>    have to copy over to a new drive. This is not
>>>    guarenteed to get the boot/efi sectors alas. 'dd'
>>>    is TOO literal, won't fix yer frag.
>>>
>> Never had to in years.
>> SSDs simply dont care, since a sector seek is no more expensive than 
>> 'next sector'
> 
> True, but next sector might be in the cache. Might, dunno how an SSD 
> does internal caching. There is still system caching.
> 
> 
SSD 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.


-- 
The difference bweteen a psychopath and a saint is that the psychpoath 
takes what he can and gives only what he must, but the saint gives 
everything he can and takes only what he needs.

[toc] | [prev] | [next] | [standalone]

#93181

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).

[toc] | [prev] | [next] | [standalone]

#93182

On 08/10/2026 15: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).
> 
Yes. in terms of wear levelling. No, in terms of access speeds, as you said

More important is to try not to fill them up. So the internal firmware 
has the space to shuffle and consolidate 'sectors;
-- 
“Politics is the art of looking for trouble, finding it everywhere, 
diagnosing it incorrectly and applying the wrong remedies.”
― Groucho Marx

[toc] | [prev] | [next] | [standalone]

#93201 — Re: Linux offers choice, BSD offers fragmentation

On Thu, 8 Oct 2026 15:25:21 +0100, Andy Burns wrote:

> 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.

SSDs come with an amazing amount of firmware to make them behave as
though they were conventional disks to the OS.

Think of the overhead on performance this imposes, as well as the
potential for weird bugs. The Linux kernel includes a few filesystems
that are purpose-built to operate on raw flash devices, by including
wear-levelling directly into their allocation algorithms.

I think these are deployed in embedded applications. But imagine if
you had the option to use them and bypass the pretend-to-be-a-disk
firmware on consumer devices.

[toc] | [prev] | [next] | [standalone]

#93231

On 10/8/26 10: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).

   SSDs do get rid of a lot of the physical issues
   with storage. Mag disks have more to cope with
   more speed/capacity decay issues.

   As for 'more writes' ... even the SSDs are so
   relatively slow that it barely matters. The
   CPU is doing a lot of waiting, time to send
   100, or 1000, blocks anywhere IF the device
   could keep up.

[toc] | [prev] | [next] | [standalone]

#93250

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🇪🇺.

[toc] | [prev] | [next] | [standalone]

#93263 — Re: Linux offers choice, BSD offers fragmentation

On Fri, 9 Oct 2026 20:47:45 +0200, Carlos E. R. spouted more AI slop:

> I asked chatgpt (as a glorified documentation search engine):

A search engine gives references.

> 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.

This is what an OS filesystem cache does, too. So now you’re going
through *two* layers between the application and its data: the OS
filesystem implementation itself, plus an additional filesystem-like
layer within the drive. All that is extra overhead.

> 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.

Also one that doesn’t actually work, unless your OS filesystem cache
is useless.

[toc] | [prev] | [next] | [standalone]

#93266 — Re: Linux offers choice, BSD offers fragmentation

On 2026-10-09 23:20, Lawrence D’Oliveiro wrote:
> On Fri, 9 Oct 2026 20:47:45 +0200, Carlos E. R. spouted more AI slop:
> 
>> I asked chatgpt (as a glorified documentation search engine):
> 
> A search engine gives references.

So does the AI, but you need to do another operation to collect them.

> 
>> 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.
> 
> This is what an OS filesystem cache does, too. So now you’re going
> through *two* layers between the application and its data: the OS
> filesystem implementation itself, plus an additional filesystem-like
> layer within the drive. All that is extra overhead.
> 
>> 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.
> 
> Also one that doesn’t actually work, unless your OS filesystem cache
> is useless.


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#93293 — Re: Linux offers choice, BSD offers fragmentation

On 10/9/26 17:20, Lawrence D’Oliveiro wrote:
> On Fri, 9 Oct 2026 20:47:45 +0200, Carlos E. R. spouted more AI slop:
> 
>> I asked chatgpt (as a glorified documentation search engine):
> 
> A search engine gives references.
> 
>> 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.
> 
> This is what an OS filesystem cache does, too. So now you’re going
> through *two* layers between the application and its data: the OS
> filesystem implementation itself, plus an additional filesystem-like
> layer within the drive. All that is extra overhead.

   This is why even SSDs don't really live up to
   their full potential. Every OS just still kind
   of assumes magnetic drives.

   And even SSDs/M.2s, compared to DRAM, SLOW !

>> 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.
> 
> Also one that doesn’t actually work, unless your OS filesystem cache
> is useless.

   It's all "best kludge". The main idea is to make
   the system work with 'everything'. Performance
   is kinda secondary.

[toc] | [prev] | [next] | [standalone]

#93364 — Re: Linux offers choice, BSD offers fragmentation

On 10/9/26 17:20, Lawrence D’Oliveiro wrote:
> On Fri, 9 Oct 2026 20:47:45 +0200, Carlos E. R. spouted more AI slop:
> 
>> I asked chatgpt (as a glorified documentation search engine):
> 
> A search engine gives references.
> 
>> 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.

   On the BSDs ... they ARE "Fit For Purpose"
   and very secure.

   But NOT quite as 'versatile' as the latest
   Linux distros.

   MOSTLY they are meant for outward-facing
   SERVERS ... and do their job very well.

   However, if you are willing to step back just
   a few years, they are perfectly good personal
   operating systems.

   Nicest, for now, "GhostBSD". Not THAT much
   different from vanilla Debian.

   The BSDs are an "out" ... if/when Linux gets
   just TOO stupid you CAN go to the BSDs and
   not suffer TOO much.

   People with 'exotic' needs, MAY not be your
   cup-o-tea however. "Basic Users" though ...

   I've kept in touch with the BSDs since forever.
   NOT my first choice, but a FAIR alt choice
   Just In Case. Do have a little box with Ghost
   set up even now. If the next-gen Linux distros
   go just TOO stupid .......

   And there's always "Plan-9" :-)

   Don't forget Solaris/OpenIndiana either.

   Look, 'popular' pressures will always push
   the Linux distros out into the blue. This
   will NOT always be a good thing, not at all.
   BEST to cultivate some 'retro' stuff.

   I bought a number of mini-boxes a couple of
   years ago when they were cheap. This is my
   reserve. IF needed, BSD/Solaris/Whatever.

[toc] | [prev] | [next] | [standalone]

#92956

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 05/10/2026 08:14, c186282 wrote:
>> MANY choices these days ... a lot better than Winders.
>> 
>>  Linux is "fairly" resistant to disk fragmentation, better than Win 
>>  for the most part.  Some of the utils can kind-of deal with it.  
>>  However if things get really bad, like on a server drive, in the 
>>  end you have to copy over to a new drive.  This is not guarenteed 
>>  to get the boot/efi sectors alas.  'dd' is TOO literal, won't fix 
>>  yer frag.
>> 
> Never had to in years.
> SSDs simply dont care, since a sector seek is no more expensive than 
> 'next sector'

Exactly.

>>  Some say that frag is NOT important anymore due to e-disks.  
>>  Sort-of true, sort-of not.  In the end you will get more and more 
>>  kinda unusable sectors.
>> 
> More ignorant bollocks

Our human-AI hallucinating yet another incorrect answer to a question 
no one asked.  He's hallucinating worn out SSD "sectors" and the SSD 
remapping system as if they have something to do with fragmented files.

[toc] | [prev] | [next] | [standalone]

#92961

On 05/10/2026 19:57, Rich wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 05/10/2026 08:14, c186282 wrote:
>>> MANY choices these days ... a lot better than Winders.
>>>
>>>   Linux is "fairly" resistant to disk fragmentation, better than Win
>>>   for the most part.  Some of the utils can kind-of deal with it.
>>>   However if things get really bad, like on a server drive, in the
>>>   end you have to copy over to a new drive.  This is not guarenteed
>>>   to get the boot/efi sectors alas.  'dd' is TOO literal, won't fix
>>>   yer frag.
>>>
>> Never had to in years.
>> SSDs simply dont care, since a sector seek is no more expensive than
>> 'next sector'
> 
> Exactly.
> 
>>>   Some say that frag is NOT important anymore due to e-disks.
>>>   Sort-of true, sort-of not.  In the end you will get more and more
>>>   kinda unusable sectors.
>>>
>> More ignorant bollocks
> 
> Our human-AI hallucinating yet another incorrect answer to a question
> no one asked.  He's hallucinating worn out SSD "sectors" and the SSD
> remapping system as if they have something to do with fragmented files.

It is weird that this conversation seems to crop up, as if there were 
some actually relationship between a sector as seen by the operating 
system and a physical RAM location on the SSD.

There is none. The SSD is running its own operating system  with  caches 
and write behinds , wear levelling, block erases and block reallocation.

The only think it needs to know from Linux is if a block is no longer 
required via the fstrim command, which is run under cron on most distros

The only thing you can do to extend SSD  lifetime is not fill the disk 
completely.


-- 
“It is hard to imagine a more stupid decision or more dangerous way of 
making decisions than by putting those decisions in the hands of people 
who pay no price for being wrong.”

Thomas Sowell

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web