Michael wrote: > Ah, but since fstrim works only on a mounted filesystem, there is > already a difference to a reset by SSD BIOS. A filesystem allocates > lots of blocks, for tables and journal and the redundancy > backups. (I wonder if that's even anymore useful with a SSD, and if > there are specific SSD mkfs options to drop all that?)
It is still needed because that protection protects against a kernel crash while the file system is only partially updated. I think you are micro-optimizing way too much. If you have a quality SSD then the vendor will already have established enough "overprovisioning" to handle this acceptably. The trim command is a way to provide additional dynamic overprovisioning that can help out the ssd. But it is a help to it. The SSD does not require it. And the better quality SSDs already provide enough to ensure performance. The use of trim, I imagine, helps low quality vendors who have skimped on overprovisioning and didn't provide enough in the original firmware. I am a huge believer in real benchmark data. Unfortunately this is hard to track over time because vendors change firmware at their discretion and do not publish details of it. Vendors consider that firmware to be their golden trade secret. This means any benchmark data is hard to correlate across years as a firmware change can invalidate all of it very quickly. Your 64G SSD could be replaced with a good quality Intel 120G for $75 today from NewEgg. Intel provides high quality firmware with significant overprovisioning and no extra is required. > A little offtopic, but while we are at 'lifetime optimization': I > also wonder about swap space. Is it still needed for hibernation or > is there a 'pagefile.sys' option in the linux subsystem > (pm-utils?). That question shows your previous computer affiliation. :-) > But as i've understood, any separation by partitions > would lead to less freedom for the SSD to allocate free cells, > because there shall be as much free space as possible, thus i should > do only the essential split into / and /home. SSDs do not operate that way. The external API will be about logical blocks starting and ending between two logical addresses. Internally those blocks are always in motion. There SSD firmware maintains a mapping table between where a block logically exists and where it physically exists. (Same thing for spinning media these days too.) The visible logical address of data is meaningless to say where those blocks are mapped to physically. Remember that SSDs erase data in large blocks. I think the smallest block for erase is 8M. Therefore when one writes a bit it isn't just the 512 byte block that gets written. Eventually it will be a much larger block. Also there is write-leveling needed. If one wrote to the same logical address repeated that should not be writing to the same physical cells. Therefore the mapping is always in motion and the SSD firmware is always moving those physical blocks around even though the logical address stays constant. > Which would be necessary for the chance to re-install another OS > some day. For example, one w/o sysetmd ! > Anyway, if there is a way to tell installers to keep a /home folder, > then even that would not be required. People often do just that with maintaining a /home that is untouched upon system installation. It is a very common scheme. Myself I prefer to have a good backup elsewhere. Bob
signature.asc
Description: Digital signature
