[Btrfs-devel] btrfs and Solid State Disks (SSD).
chris.mason at oracle.com
Mon Feb 11 12:13:37 PST 2008
On Monday 11 February 2008, Miguel Figueiredo Mascarenhas Sousa Filipe wrote:
> Hi there,
> This might sound stupid, but since I cannot infer from the
> documentation and features of btrfs the answer to my doubts.
> Here it goes:
> Is the data and metadata ondisk layout of btrfs favorable for SSDs ?
Yes, SSDs are a big target of mine, and so the parts that are not currently
favorable for SSDs will be changed. The big problem right now is that btrfs
writes to a fixed super block for every commit. That will change to a
rotating set of fixed super blocks to lower wear and improve redundancy.
> >From what I read, current SSD are characterized by:
> - poor performance in random writes (because of block erasure)
Random writes are very fast, as long as they fill an entire erasure block
(often 128KB) There are rumors that SSDs will have smaller erasure blocks in
> - require wear leveling, even those that emulate sata/ide/scsi disk
> with onboard wear leveling logic.
Yes, they all require wear leveling, and usually they do this internally.
Btrfs will not do wear leveling.
> - excellent seek latency
> - excellent read (random and sequential) performance.
> - good at sequential writes.
> I've read that journaling file systems are usually bad for SSD because
> of (from what I suppose are) two things:
> - increased "random" write load (journal + proper data)
> - write hot spot on the journal, causing lots of write cycles on a
> given set of blocks.
> Theoretically, ext2 would be better for a SSD than ext3 because of these
Journaled filesystems will definitely exercise the wear leveling firmware, but
so will ext2. The metadata and file data blocks are in a fixed location and
use small block sizes. So, metadata heavy workloads will hammer on the SSD
> So, is the design of btrfs a good match for the peculiarities of SSDs ?
Yes, because Btrfs is copy on write it is able to always cluster metadata and
data writes in an optimal fashion on the SSD. On traditional storage you get
very bad performance with this type of allocation model because it will have
many more seeks on reads. But with SSD, there is no read penalty.
With v0.12, I introduced a knob to tune the allocator for SSD (clearly there
is much more work to do here). You mount with -o ssd to enable the tuning.
Here is an example graph on an SSD device with postmark, which basically does
random writes to a bunch of files:
Here is the same workload on a traditional sata drive, but with ext3 in the
Notice that on the spinning sata drive btrfs -o ssd isn't much faster overall.
This is because write cache is enabled on the drive, without the cache on -o
ssd is about 2x faster than the defaults.
More information about the Btrfs-devel