Chris Mason <chris.mason <at> fusionio.com> writes: > There are three basic problems with the database workloads on btrfs. > First is that we have higher latencies on writes because we are feeding > everything through helper threads for crcs. Usually the extra latencies > don't show up because we have enough work in the pipeline to keep the > drive busy. > > I don't believe the UEK kernels have the recent changes to do some of > the crc work inline (without handing off) for smaller synchronous IOs. > > Second, on O_SYNC writes btrfs will write both the file metadata and > data into a special tree so we can be crash safe. For big files this > tends to spend a lot of time looking for the extents in the file that > have changed. > > Josef fixed that up and it is queued for the next merge window. > > The third problem is that lots of random writes tend to make lots of > metadata. If this doesn't fit in ram, we can end up doing many reads > that slow things down. We're working on this now as well, but recent > kernels change how we cache things and should improve the results.
That's good to hear - personally I'd rather use btrfs than ZFS, but it seems we were a tad bit early to the party with this kind of workload. Interesting nobody commented on block-size, I kind of expected that when writing my initial post (database using 8KB blocks, tweakable in ZFS but apparently not in btrfs). /Casper -- 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
