Just curious!!!
I have no idea if the SSD firmware is smart enough to do either.
I don't know what event triggers wear leveling in general and how it's passed on from OS to drive, and if it's any different for swap writes as for any other write operation.
[ No need to convince me not to use swap etc., I'm already convinced! ]
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason:Topic automatically closed 6 months after creation. New replies are no longer allowed.
spamhog wrote: ⤴Fri Apr 09, 2021 3:00 pmJust curious!!!
I have no idea if the SSD firmware is smart enough to do either.
I don't know what event triggers wear leveling in general and how it's passed on from OS to drive, and if it's any different for swap writes as for any other write operation.
Wear levelling is a function of the SSD controller. The OS has absolutely no role in wear levelling, so nothing is 'passed on from OS to drive", and since wear levelling is a function of the SSD controller, it logically follows that it is not 'any different for swap writes as for any other write operation.'
Also possibly worthy of comment is the word "within" which you used: wear leveling is an SSD- (or individual flash chip-) global process, not a per file or partition one.
The only thing the SSD firmware is interested in is blocks and their status as free/used, i.e., being available or not to the wear leveling process, and in that sense the OS is somewhat involved by through e.g. the weekly fstrim runs that Linux Mint configures informing the firmware which logical blocks are as far as the OS is concerned to be considered free. Wear leveling is of course more effective the more free blocks the SSDs firmware has available to spread writes out over so the firmware being kept apprised of said free/used status regularly is certainly useful.
Mind you, a simple write to any given logical block of course also informs the firmware that the to that logical block currently underlying physical block is no longer to be considered used, and modern SSDs keep a large pool of not user accessible free blocks around in the first place, so OS involvement is not generally vital, but in that fstrim sense it does exist.
By the way, I'm not currently on Linux so can't check directly and googling for it leaves me unconvinced of a definitive answer but the above would then also be to say that there is a potential difference between filesystem writes and "swap writes" even if only in that trim sense.
I.e., yes, what with the SSD firmware not being at all interested in, aware of even, the kind of data any given logical block is used for at a higher level, certainly no difference exists as to writes themselves, but with fstrim working at the fs-level a potential difference between filesystem and swap blocks can exist in that sense of the SSD firmware knowing about blocks being free or not.
Linux Mint as said configures weekly fstrim runs by default. The swapon command has a discard=once parameter that trims the entire swap space "if the underlying device supports it" which would mean it's trimmed on every reboot at least, but that formulation already has me wonder if there would be a difference between a swap file and swap partition: latter would be more commonly referred to as a "device" than former. Moreover, although google seems to suggest that the kernel in fact trims on swapon automatically anyway I then wonder why the e.g. swapon man page seems to not mention that --- and again if any such potential kernel-level default would carry over to a swapfile on a trim-supporting fs: I expect it would not, filesystems living at a higher conceptual level than swapspace.
I.e., non too clear. Although, note, still just talking about the trim behavior which is in the end and with modern hardware a detail.
rene wrote: ⤴Sat Apr 10, 2021 4:35 am
...Wear leveling is of course more effective the more free blocks the SSDs firmware has available to spread writes out over so the firmware being kept apprised of said free/used status regularly is certainly useful...
And that is one reason why one should leave 20-25% free space (unused formatted capacity) on an SSD in addition to the factory set over-provisioning (which one should never change). Also, TRIM will use up less write life due to write amplification when adequate free space is maintained. If one just mostly reads on an SSD, one can safely get away with only 20% free space. If one frequently deletes some data and writes new data, then 25% is necessary.
Jeannie
To ensure the safety of your data, you have to be proactive, not reactive, so, back it up!
Lady Fitzgerald wrote: ⤴Sat Apr 10, 2021 10:23 am
And that is one reason why one should leave 20-25% free space (unused formatted capacity) on an SSD [ ... ]
I'd definitely not advise that, no. Modern SSDs have ample overprovisioning space OOTB. Note for example how they tend to be sold as e.g. 1TB drives whereas you can be sure they'll in fact have 1TiB of flash, i.e., almost 10 percent more. Even back when they didn't the usually quoted figure was 7% manual overprovisioning; 20-25% approaches criminal waste of resources.
And especially by the way if you're not in the habit of filling up your filesystems completely anyway: as per this thread, free blocks are free blocks to the SSD firmware, be they part of filesystems, swap space, partitioned or unpartitioned space (or "unused formatted capacity" as you say) or even of an e.g. ATA HPA which for example Samsung tended to use, long ago. You have to these days be pretty special as to write patterns so as to not be fine with simply no manual overprovisioning at all.
Lady Fitzgerald wrote: ⤴Sat Apr 10, 2021 10:23 am
And that is one reason why one should leave 20-25% free space (unused formatted capacity) on an SSD [ ... ]
I'd definitely not advise that, no. Modern SSDs have ample overprovisioning space OOTB. Note for example how they tend to be sold as e.g. 1TB drives whereas you can be sure they'll in fact have 1TiB of flash, i.e., almost 10 percent more. Even back when they didn't the usually quoted figure was 7% manual overprovisioning; 20-25% approaches criminal waste of resources.
And especially by the way if you're not in the habit of filling up your filesystems completely anyway: as per this thread, free blocks are free blocks to the SSD firmware, be they part of filesystems, swap space, partitioned or unpartitioned space (or "unused formatted capacity" as you say) or even of an e.g. ATA HPA which for example Samsung tended to use, long ago. You have to these days be pretty special as to write patterns so as to not be fine with simply no manual overprovisioning at all.
BTW, over-provisioning and free space have different functions although they are similar and overlap. An SSD will seem to function fine without 20-25% free space (in addition to over-provisioning) but, for TRIM and wear leveling to work without causing write amplification (which, in addition to more rapidly using up write life, also can slow down an SSD), there has to be enough free space for for the SSD to rewrite data onto unused blocks. When there aren't enough unused blocks to write to, then write amplification occurs.
You originally said "unused formatted capacity" which I read wrong: to that bit, yes, sure, that's the same thing that I also said concerning "if you're not in the habit of filling up your filesystems completely anyway". Even if not in the context of overprovisioning one should definitely also in the context of filesystems themselves and their layout choices leave some free space available.
Other than that though, and as the point of both this thread and my reply, no, overprovisioning and free space end up not having different functions in the context of former. As said, to the SSD firmware free blocks are free blocks be they on a higher level part of a filesystem or not, and when in the former case told to be free blocks by trim and/or garbage collection.
That's the point here: moderns SSDs have a large pool of not user accesible blocks anyway, and if you're not in the habit of completely filling up your filesystems anyway the firmware still has a lot more to play with even than that. What certainly no one should do any more is as how I originally and wrongly interpreted your statement, i.e., keeping 20-25 percent of space unpartitioned or as a fully unused partition.
]
