Фрагментация является в значительной степени неизбежным побочным эффектом файловой системы, спроектированной с копированием при записи. Это также то, что позволяет практически бесплатно делать снимки файловой системы.
Причина этого довольно проста: каждый раз, когда блок изменяется, новый блок должен быть записан в другое место, отличное от исходного блока. Таким образом, даже если файл изначально был смежным, он не будет изменен.
Я не знаю, как Btrfs nodatacow взаимодействует со снимками, но у меня есть ощущение, что в момент, когда у вас есть снимок в наборе данных, вы запускаете по крайней мере частичное поведение копирования при записи независимо от того, какие флаги вы используете; в противном случае, как вы сможете получить доступ к старым данным через снимок?
Однако не обязательно, что это обязательно серьезно повлияет на производительность MySQL по двум причинам:
- Современные диски действительно довольно быстрые для однопользовательских рабочих нагрузок (я полагаю, что вас это больше всего интересует, потому что вы упоминаете, что ваша система является "рабочей станцией")
- Современные операционные системы имеют довольно хорошие алгоритмы кеширования, тем самым уменьшая необходимость в использовании физического хранилища
Просто чтобы дать вам представление, я сам запускаю ZFS (у которой Btrfs заимствует много идей), и в настоящее время идет процесс разработки. Рассматриваемый пул представляет собой шестидисковый raidz2, который на самом деле не известен своей звездной производительностью, физически обеспеченный шестью дисками 7200 об / мин (два SATA, четыре SAS), которые также точно не известны, в частности, для звездного IOPS. Скраб ZFS просматривает все дерево Merkle на диске, считывает все данные и проверяет контрольные суммы на всем, чтобы убедиться, что все считывает обратно, как это было ранее записано; в моем случае вычисление SHA-256 хешей всего на этом пути. Текущая скорость очистки (после того, как она преодолела начальную, тяжелую метаданную часть, которая включает в себя тяжелый поиск) колеблется прямо около 200 МБ / с и фактически медленно поднимается. И это для фактической тарелочки I / O, без кэширования вовлеченного (поскольку кэширование не имеет никакого смысла , если вы хотите , чтобы убедиться , что на постоянном хранении).
Конечно, очень вероятно, что вы увидите некоторое снижение производительности из-за фрагментации, если перейдете к файловой системе копирования при записи. Но вы не можете съесть торт и сохранить его тоже; если вам нужны быстрые, недорогие снимки, скорее всего, вам придется отказаться от чего-то другого, чтобы получить их.
То, что я бы сделал в вашем случае, является эталоном. Настройте некоторое хранилище Btrfs, поместите туда копию базы данных MySQL и посмотрите, как они работают при разумных рабочих нагрузках.
