Austin, I recognize there are other components too. In this case I'm actually comparing BTRFS to XFS and EXT4 so I'm 100% sure it is file system related. Also I'm using O_DIRECT asynchronous IO with MySQL which means there are no significant dirty block size on the file system level.
I'll see if it helps though Also I assumed this is something well known as it is documented in Gotchas here: https://btrfs.wiki.kernel.org/index.php/Gotchas (Fragmentation section) > > It's worth keeping in mind that there is more to the storage stack than just > the filesystem, and BTRFS tends to be more sensitive to the behavior of > other components in the stack than most other filesystems are. The stalls > you're describing sound more like a symptom of the brain-dead writeback > buffering defaults used by the VFS layer than they do an issue with BTRFS > (although BTRFS tends to be a bit more heavily impacted by this than most > other filesystems). Try fiddling with the /proc/sys/vm/dirty_* sysctls > (there is some pretty good documentation in Documentation/sysctl/vm.txt in > the kernel source) and see if that helps. The default values it uses are at > most 20% of RAM, which is an insane amount of data to buffer before starting > writeback when you're talking about systems with 16GB of RAM. > -- Peter Zaitsev, CEO, Percona Tel: +1 888 401 3401 ext 7360 Skype: peter_zaitsev -- 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
