Deutsch   English   Français   Italiano  
<vms0h7$1965j$2@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.os.linux.misc
Subject: Re: News : ARM Trying to Buy AmperComputing
Date: Wed, 22 Jan 2025 23:55:19 +0000
Organization: A little, after lunch
Lines: 41
Message-ID: <vms0h7$1965j$2@dont-email.me>
References: <_hycnQxlN5kAphr6nZ2dnZfqn_SdnZ2d@earthlink.com>
 <UcicndjNUaEg0hH6nZ2dnZfqnPSdnZ2d@earthlink.com>
 <35e42921-5781-8728-236f-afad1d3b56b1@example.net>
 <vSydnd3xKfdNFhD6nZ2dnZfqn_udnZ2d@earthlink.com>
 <7258fd01-44f7-850d-3f69-54b93489f64d@example.net>
 <vml7e7$31s95$1@dont-email.me>
 <69ce04cf-80a7-7170-675f-4165ffedc92b@example.net>
 <RtudnVi93qkPcBP6nZ2dnZfqnPudnZ2d@earthlink.com>
 <4985abd5-ec8c-44da-0105-0778434959c0@example.net>
 <vmou5k$bc8h$1@dont-email.me> <vmq7sv$rr50$3@dont-email.me>
 <vmrj85$16674$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Jan 2025 00:55:20 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ed8d6d6cb5eef7bc39bee57f08067766";
	logging-data="1349811"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Ly281lDdFsh2XQMtItzTVo4FXdJl6SpI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:icTQLYq4iI2aXhcp2UdDQ6g9+F4=
Content-Language: en-GB
In-Reply-To: <vmrj85$16674$1@dont-email.me>
Bytes: 3314

On 22/01/2025 20:08, Rich wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 21/01/2025 19:56, Rich wrote:
>>> For SSD's, writes occur to an "erased" flash block (typically much
>>> larger than a "disk sector" size used by the host) and given enough
>>> writes over a short enough timeframe the SSD controller can run out of
>>> "pre-erased" blocks to use, and when that happens write speed slows
>>> down to the rate that can be done when a "block erase" has to occur
>>> before the actual writes can hit the media.  Note that this "block
>>> erase" can also invove moving any partially used data sectors out of
>>> the block into another block, creating a "write amplification"
>>> situation as well.
>>
>> One of the best ways to gain speed and longevity is to buy an SSD that
>> is way larger than you need. So it always has empty blocks available.
> 
> And hope it has a decent block layer that spreads the writes around so
> no one part of the flash is written to more than any other parts.
> 
That is pretty much standard practice these days Its called 'wear levelling'

>> And can do the block erases in background
> 
> Most SSD's do erases in the background, so that they can have empty
> blocks waiting to absorb writes.
> 
....Exactly...
> But stream a large enough set of writes at the drive, and you can (for
> some drives) use up the queue of background erased blocks and then you
> see your write speed drop by a good amount because the block erases are
> now also part of the "write path" for your data heading at the drive.

.....that was precisely the point I was making.


-- 
"If you don’t read the news paper, you are un-informed. If you read the 
news paper, you are mis-informed."

Mark Twain