Re: SDD partitioning and allocations
Somehow, the newlines in your post got lost (?).
On 7/14/25 11:12, Borden wrote:
2025-07-14 11:37:17 dpchrist@laalaa ~
$ perl -pe 's/>/\n>>/g' foo | perl -pe 's/\. ?/.\n> /g'
My unsolicited, unprofessionl, free advice:
>> Is it better than fstrim.
> timer mentioned in this thread?
>>
>> Some years ago there was a warning on the
>> <https://wiki.
> archlinux.
> org/title/Solid_state_drive/NVMe
>>
>>
>> page that Intel did not recommend continuous TRIM aka discard.
> Currentlythere are some words against discard in
>> <https://wiki.
> archlinux.
> org/title/Solid_state_drive#Continuous_TRIM
>>.
>
>>
>>
>> Do you have more details on this story, what was behind Intel
suggestionand what has changed since that time?I just set 'ssd' in fstab
options and leave it.
> From my reading (which I unfortunately can't cite and could be wrong)
when SSD was a newish technology, file and operating systems had to play
catchup.
> To my understanding, that's mostly been done, so the default SSD
options ought to be sufficient.
> Like, I had to tell my Windows clients years ago not to defragment
their SSD, because it would cause unnecessary writes.
> Microsoft has since updated their defragment command not to do that
(and they've further renamed it as 'optimise') so now I can tell my
clients to optimise however often they like.
> I understand that Linux is much the same, if not a little ahead of
the curve.
> My understanding is that setting constant ftrim and/or discard just
hogs bandwidth, as the firmware busily clears writeable memory instead
of doing what you want it to do.
I expect that depends upon the drive hardware and firmware; notably
parallelism -- can the drive controller tell the hardware to read one
block, write another, and erase a third, all in parallel? Two in
parallel? Or, one at a time (sequential)? Assuming operations are
queued, what are the priority policies? STFW "ssd architecture"
produces some interesting articles:
https://html.duckduckgo.com/html?q=ssd%20architecture
>> As to secure erase, I have seen comments claiming that sometimes
ithelps to recovery performance degraded after some period of usage.
> Ihave not tried to collect details if it is related to specific
models orto low end drives.
I have some old Samsung UM410 16 GB SSD's. AFAICT they do not support
discard or trim.
> I don't understand that logic.
> I've been told to believe that SSDs have finite write cycles, so you
don't want to change a 1 to a 0 if you'll only have to change it back to
a 1 again when you save something.
> I've also read that the firmware tries to optimise writes, so
abstracts access to the hardware.
> Therefore, where you can tell a HDD to "fetch sector X of platter Y,"
there's no analogue in an SSD.
> The file system just says "fetch me address Z," and the firmware
figures out which cell of which chip by magic.
> Furthermore, I understand that telling an SSD to write a terabyte of
zeros to the drive may not actually write a terabyte of addresses, as
the SSD firmware will try to economise writes to reduce wear.
> I understand that the only way to wipe an SSD securely is to
re-encrypt the drive, as the SSD will then take the protective measures
to make the data inaccessible without a password.
> But, please, I encourage the people here who are smarter than I am to
correct any of my factual inaccuracies.
>
>> Today's SSDs, even consumer brands, have much higher endurance, and
thissort of advice is quite complicated and consumer-hostile, so you
don'tsee it any more.
> I have a fairly inexpensive Crucial 2TB that I do all my living on.
> It was a Samsung but their customer service was horrific so I'm
boycotting them now.
> It runs at about 80% full.
> Aside from disabling swap, I use my computer without considering writes.
It has been a while, but I found that disabling swap with Linux caused
the desktop to fall apart under memory pressure as processes were killed
off. So, now I allocate a 1 GB swap partition.
> I regularly download, delete, change my mind, download the same thing
again, write a script that outputs to a file, then run the same command
dozens of times as I debug it, and so on.
> I even had BOINC running on it until recently.
> Nevertheless, I check the SMART readout every so often.
> It's down to about 96% health after about 2-3 years of regular use.
> At this rate, I'll probably have to replace the drive in about 40 years.
> So I'm not losing sleep, and neither should you.
The consensus appears to be that continuous erasure (e.g. fstab(5)
"discard" option) is undesirable and that periodic erasure (e.g.
fstrim.timer or fstrim(8)) is preferred.
And, there are plenty of other possibilities if you care to STFW,
including fstab(5) / mount(8) "noatime", "nodiratime", "relatime", and
"commit", RAM disks, sync tools, etc..
David
Reply to: