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 the future. > - 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 > issues. 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 either way. > > 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: http://oss.oracle.com/~mason/seekwatcher/pm-compare.png Here is the same workload on a traditional sata drive, but with ext3 in the results: http://oss.oracle.com/~mason/seekwatcher/postmark/postmark-compare.png 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. -chris _______________________________________________ Btrfs-devel mailing list Btrfsfirstname.lastname@example.org http://oss.oracle.com/mailman/listinfo/btrfs-devel