[Tfug] Small-ish (capacity + size) disk alternatives

[John Hubbard]

I'm getting tired, and I've given up on another proof reading pass.  
Please forgive anything that doesn't make sense, or sentences that I 
just don't finish. ;)

On 1/30/2013 8:17 PM, Bexley Hall wrote:
> Hi Yan,
>
> On 1/30/2013 6:58 PM, Yan wrote:
>> Hi guys,
>>
>> E.g., John's mention of "685TB of data to a 40GB (drive)" as if that
>>> was admirable.  Yet, that's just ~15,000 times the capacity of the
>>> drive (suggesting each FLASH block is rated at ~15,000 erase cycles).
>>>
>>> Said another way, if you had 39GB of "executables" (i.e., data that
>>> is never altered) on the drive, you might be limited to writing
>>> ONLY ~15,000GB over the *life* of the drive.  An application that
>>> wrote to the disk at 15MB/s would kill the drive in ~2 weeks! (!!)
>>
>> You're describing dynamic wear leveling, whereas I think pretty much any
>> SSD worth its salt nowadays uses static wear leveling (see,
>> http://thessdguy.com/how-controllers-maximize-ssd-life-better-wear-leveling/). 
>>
>> Although
>> for all I know, that might not apply to the smaller, cheaper ones.
>
> It doesn't matter.  Would you expect your traditional (magnetic)
> disk to wear out once (15,000 * capacity) of data was written to it?
> Imagine if *RAM* had a similar *inherent* limitation!

I thought that we were looking at using SSDs to replace HDDs.  Last time 
I checked HDDs DID wear out.  Your problem is HDDs wear out. The 
suggested solution is SSD.  You are correct that SDDs wear out, just 
like the HDD that it is being suggested as a replacement for. It is a 
non sequitur to say start comparing RAM (which admittedly doesn't wear 
out) with an HDD replacement which (just like the HDD its replacing) 
does wear out.

> And, the actual amount of "work" that you are calling on the drive
> to do (measured in terms of bytes "written") can be considerably less
> than that "15000 C" number!  E.g., I might want to update a single
> byte per sector/cluster/FLASH block yet this "costs" as much (in
> terms of endurance) as if I had rewritten the entire sector/block!

You are talking like ever bit written to memory will lead to a new 2k 
write on the SSD.  The system keeps the most used data in ram and only 
flushes to swap when there isn't enough room.  If you are really as 
space constrained as you claim you are, your system would be unusable.  
When a system is frantically writing to swap, it bring it to its needs 
and makes it unusable.  You'd know if you were doing it that often.  You 
aren't hitting it /that/ hard.  This means that at least some of these 
bits that you are writing are being written to the ram, and the changes 
will only go to swap when there are enough in ram.

> As newer, multilevel processes become more commonplace, you'll see
> densities go up -- and endurances go *down*!

But as densities go up cost/GB goes down.  If the PE cycle is cut in 
half, but you get twice space, it will be nearly a wash.

>
> Static wear leveling also poses problems for caching and asynchronous
> access as the drive has to be able to remap data that is already
> "safe and secure" to blocks that may *not* be!  I.e., attempting
> to move "existing data" can fail. 

So what.  This is what they do.  If you have stuff that is never being 
written (only read) the controller will move it to a frequently written 
cell.  It will do this before it thinks that there is only one write 
left on that target cell.  Even if the cell fails, so what.  Cells 
fail.  Those cells are marked as bad, and the drive uses other cells.  
ALL modern SSDs have spare area.  They can (and do) handle cell failures.

> So, the drive can't erase the
> "good" instance of the data until/unless it has successfully
> moved it. 

Again so what.  This is what they do.

> As a result, freeing up blocks that one would *think*
> still have some wear left in them can be problematic. 

I fail to see the problem.  SSD controller have a complicated job to do, 
and they do it.  That is a problem for the poor engineer who has to come 
up with the algorithms, and test them, but not for you and I.  If you 
are really worried about it buy a SSD from a bigger manufacturer with 
more testing/QA.  Intel comes to mind, but I'm sure that there are others.

> But, the drive
> can't report this problem 

This isn't a problem.  This is like ECC memory.  It gets fixed, you get 
the correct data, and everyone is happy.

> until long after the *need* to make that
> space available (e.g., if data is residing in R/W cache waiting to
> be committed to FLASH). 

Drives have spare area.  They have space to hold a few extra bits while 
they are shifting other things around.  If you 'fill' up a drive it 
won't be full.

> I.e., it makes the drive behave as if it
> was "slow with a large cache" 

Define slow.  Its a heck of a lot faster than the HDD that I'm 
suggesting you get rid of.

> -- the application isn't notified of
> writeback failures until long after the write operation that was
> responsible has "completed".
>
> Again, this is a consequence of the decoupling of the storage
> media from the application (because of all the *bloat* that
> exists in the region between the two)
>
>>> (similarly, assuming you could write to the *entire* media "at will",
>>> you're looking at 80 weeks).
>>
>> With the price of SSDs nowadays (provided that they do support static 
>> wear
>> leveling), that might not be too bad, and possibly not too much more
>> expensive (and if trends continue, might even be cheaper soon).
>
> You're missing the point.  Would you want to have <whatever>
> require replacement/servicing in that short an interval?
>
> E.g., would you want to replace/repair (labor cost$) your DVR
> because "the disk wore out"?  (in that time frame)  Or, your
> PC?  In my case, should the entire multimedia/automation system
> grind to a halt because the disk "wore out"?

Would you be sure to send us the link to those HDDs you're using that 
never fail?

> Do I design something with a built-in/inherent replacement date?

Is the whole thing passively cooled or are you using fans?  Will those 
fans last forever?  Just about anything will have some part that will 
eventually stop working properly.  Rather than design it so that it 
works forever ask yourself how long people will want to continue using 
it, and make sure it lasts that long.  The average smart phone has to 
last what 2 years?

> Instead, you (I) look for technologies that let you avoid these
> limitations.  This is a lot easier to do in hindsight; considerably
> harder in foresight!  :-/

You are avoiding one limitation (SSD finite erase/program cycle) but 
with HDDs you still suffer mechanical wear and tear.  As you noted in 
your original email the HDDs you've been using "die pretty easily".  You 
are the one looking for a better solution.  I haven't seen many 
suggestions beyond SSDs.  If your plan is to dismiss SSDs you might need 
to consider changing usage pattern, instead of just switching around 
some hardware.

> I.e., you can't quantify the data access/update patterns until
> you can actually *measure* them.  And, until you've identified them,
> you can't *alter* them to place less stress on the media.

If you don't fully understand your data access/update patterns it 
doesn't seem like you can say whether or not they will overly burden an 
SSD.  Are these systems entering production tomorrow?  If not, roll the 
dice?  Its called development for a reason.  Try an SSD, monitory the 
Media Wear-Out Indicator (MWI) and you will get some idea of just how 
abusive your usage model really is.



-- 
-john

To be or not to be, that is the question
                 2b || !2b
(0b10)*(0b1100010) || !(0b10)*(0b1100010)
         0b11000100 || !0b11000100
         0b11000100 || 0b00111011
                0b11111111
255, that is the answer.