Replacing Drive with SSD

[Brandon J. Wandersee]

RW via freebsd-questions writes:

> On Mon, 31 Aug 2015 12:52:43 -0400
> Quartz wrote:
>
>> >
>> > It provides a pool of blocks that have not and will not be
>> > written.  
>> 
>> Bbut how does the drive "know" that those blocks are not allocated by
>> a partition somewhere and are safe to use as spares? It's not like
>> the drive firmware reads into the partition table or anything.
>
> It's analogous to virtual memory. It's the unused physical blocks that
> form the free pool. The point of leaving the unpartitioned space is
> that it's a region of a logical address space with no physical blocks
> attached.

Just to expand on this a little more (since it confused me as well after
I bought my first SSD): solid-state drives do not write data to
contiguous blocks, and "partitioning" the drive does not place actual
barriers at physical points on the disk as is done with an
HDD. The operating system sees SSD and HDD paritions in the same way,
but on an SSD partitions function more like filesystem quotas.

Leaving blocks unpartitioned doesn't mean those blocks won't be written
to; it just ensures that a certain amount of space (and so a certain
number of blocks/cells) must always be free, forcing writes to be spread
across different physical portions of the disk in a relatively even
manner. It's my understanding that this over-provisioning isn't
exactly necessary in most SSDs nowadays. It just serves as a stronger
guarantee than entrusting everything to a drive's firmware.

-- 
=================================================================
   		      :: Brandon Wandersee ::
                  :: brandon.wandersee at gmail.com ::
==================================================================
'A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.'
                            			- Douglas Adams
==================================================================