| 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