Re: SSD Optimizations

[Chris Mason <chris.mason@oracle.com>]

On Wed, Mar 10, 2010 at 07:49:34PM +0000, Gordan Bobic wrote:
> I'm looking to try BTRFS on a SSD, and I would like to know what SSD
> optimizations it applies. Is there a comprehensive list of what ssd
> mount option does? How are the blocks and metadata arranged? Are
> there options available comparable to ext2/ext3 to help reduce wear
> and improve performance?
> 
> Specifically, on ext2 (journal means more writes, so I don't use
> ext3 on SSDs, since fsck typically only takes a few seconds when
> access time is < 100us), I usually apply the
> -b 4096 -E stripe-width = (erase_block/4096)
> parameters to mkfs in order to reduce the multiple erase cycles on
> the same underlying block.
> 
> Are there similar optimizations available in BTRFS?

All devices (raid, ssd, single spindle) tend to benefit from big chunks
of writes going down close together on disk.  This is true for different
reasons on each one, but it is still the easiest way to optimize writes.
COW filesystems like btrfs are very well suited to send down lots of big writes
because we're always reallocating things.

For traditional storage, we also need to keep blocks from one file (or
files in a directory) close together to reduce seeks during reads.  SSDs
have no such restrictions, and so the mount -o ssd related options in
btrfs focus on tossing out tradeoffs that slow down writes in hopes of
reading faster later.

Someone already mentioned the mount -o ssd and ssd_spread options.
Mount -o ssd is targeted at faster SSD that is good at wear leveling and
generally just benefits from having a bunch of data sent down close
together.  In mount -o ssd, you might find a write pattern like this:

block N, N+2, N+3, N+4, N+6, N+7, N+16, N+17, N+18, N+19, N+20 ...

It's a largely contiguous chunk of writes, but there may be gaps.  Good
ssds don't really care about the gaps, and they benefit more from the
fact that we're preferring to reuse blocks that had once been written
than to go off and find completely contiguous areas of the disk to
write (which are more likely to have never been written at all).

mount -o ssd_spread is much more strict.  You'll get N,N+2,N+3,N+4,N+5
etc because crummy ssds really do care about the gaps.

Now, btrfs could go off and probe for the erasure size and work very
hard to align things to it.  As someone said, alignment of the partition
table is very important here as well.  But for modern ssd this generally
matters much less than just doing big ios and letting the little log
structured squirrel inside the device figure things out.

For trim, we do have mount -o discard.  It does introduce a run time
performance hit (this varies wildly from device to device) and we're
tuning things as discard capable devices become more common.  If anyone
is looking for a project it would be nice to have an ioctl that triggers
free space discards in bulk.

-chris