[colug-432] SSD vs SD

Matt Simmons standalone.sysadmin at gmail.com
Sun Mar 17 11:53:46 EDT 2013


So, you are definitely on the right track.

The normal warnings about block alignment on disk drives definitely
still counts with SSDs (and maybe moreso).

The way that flash drives read and write data is complicated. More
complicated than I want to get into over email, but essentially,
there's a "read" block size of 4k, and an "erase" block size, and the
erase block size is several times larger than the read block size.
Since spinning disks almost all have a 4k block size now, you can
follow the standard advice on partition alignment and be ok.

And then there's performance.

The "normal", if older, way of looking at drive geometry as a series
of cylinders, sectors, and heads, has been an abstraction since it was
replaces with Logical Block Allocation (LBA) which is a completely
linear address scheme, but with SSDs, it's entirely imaginary. Flash
controllers implement a Flash Translation Layer (FTL) that takes the
linear LBA addresses (starting with block 0, then block 1, block
2...block N) and translates them into whatever its internal addressing
scheme is, which is distributed across the flash chips however it
decides to do it.

It used to be that you could take advantage of physical drive geometry
to only partition the outer edge of the platters (a technique called
"short stroking"). This took advantage of the fact that the outside
edges of hard drive platters go by faster than the inside. By limiting
seek time (by only using a certain number of tracks) on the fastest
part of the disk, you could get really outstanding performance.

Since SSDs don't have mechanical parts, and aren't subject to
distance-induced latency, short stroking them doesn't actually have
much, if any, effect on performance (at least that I'm aware of -
there may be some variable that I don't know about). But, as you
mention, it DOES have an effect on longevity.

So, if you go shopping for SSD hard drives, you'll see some really
crazy sizes that you don't normally see in hard drives. Things that
are almost, but not quite, powers of two. 120GB. 250GB. 500GB. If
that's ever made you think, "gee, that's weird", there's a reason.
There actually ARE 128, 256, and 512GB of flash chips on each of those
drives. The FTL is essentially hiding the extra space from you, but
when it goes to write, it's writing across all of the chips. This
extra overhead gives it more space to spread writes across, and
increases longevity through the same means.

Because of the way that the FTL works, you can artificially improve
longevity yourself by "short stroking" the disk - essentially by not
partitioning all of it. When you partition a 500GB SSD as 400GB, you
are essentially saying, "I'm reserving 100GB (plus the 12GB the FTL
reserves) of writes". You'll still get the same performance because
the FTL will still send each write to all of the flash chips, but by
limiting the capacity, you're limiting the number of writes over the
lifetime of the drive.

Honestly, with a personal-use flash drive, I don't know if we're going
to see people commonly running into the write lifetime limits. On one
hand, you're much more likely to stick with a hard drive beyond the 3
years that a business is going to keep the drive in use (most places
try to keep a 3-5 year straight line depreciation schedule for
hardware), but at the same time, most of us who have high capacity
drives use them for archiving data. The drives that are really in
danger of running into the write limit are those which are used as
read caches for large storage arrays, or which act as scratch space
for high-use databases. Archiving data just isn't the kind of thing
that causes write exhaustion, and even with a standard OS install, how
many times are you really swapping to disk?


--Matt

On Sun, Mar 17, 2013 at 11:26 AM, Rob Stampfli <res at colnet.cmhnet.org> wrote:
> Excellent analysis, Matt.  The question I have is how do I partition
> the drive and lay out the file systems so that the internal geometries
> of the SD or SSD are used efficiently.  My understanding is that if
> you do this correctly, you can not only extend the life of the drive,
> but also speed things up significantly.  I recently fdisked an SD for
> use in a Pogoplug and not knowing the internal segment size -- it was
> a 16 GB SD, so I guessed it was either 4 MB or 8 MB -- I arbitrarily
> chose to start each of the partitions on a multiple of 16384 512-byte
> blocks.  But, then, what additional parameters should I specify when
> creating the file systems, aside from the usual constraints of using
> ext2 to minimize write cycles.  (And, now I hear ext4 with some special
> options is a better choice...)  I'm also hearing that you should leave
> 15-25% of the drive unpopulated to give the controller better options
> in terms of assignment an wear-leveling.
>
> Any ideas in this area?
>
> Rob
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432



-- 
LITTLE GIRL: But which cookie will you eat FIRST?
COOKIE MONSTER: Me think you have misconception of cookie-eating process.


More information about the colug-432 mailing list