On Thu, 11 Mar 2010 09:21:30 -0500, Chris Mason <chris.ma...@oracle.com> wrote: > 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.
Doesn't this mean _more_ writes? If that's the case, then that would make btrfs a _bad_ choice for flash based media with limite write cycles. > 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. Thanks, that's quite helpful. Can you provide any insight into alignment of FS structures in such a way that they do not straddle erase block boundaries? > 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. Are you saying that -o discard implements trim support? Gordan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
