[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Solid State Drive BIOS update and Memory Cell Clearing

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.


Attachment: signature.asc
Description: Digital signature

Reply to: