A look at MySQL on ZFS

прим. Ком. На последнем абзаце сломал мозг :)

Если речь идёт просто FS+MySQL, то UFS вроде не самая быстрая FS, тут надо бы сравнивать ещё с EXT4, XFS.
В другом случае ответ многих — ZFS :)

Вообще говоря, на производительность и сравнение очень сильно влияет физика накопителей и шины.

The real reason for the good performance on this benchmark is not clear — indeed, every workload will be different — but the ZFS I/O scheduler, the Sun engineers paying attention to database performance, and the ZFS bug fixes contributed in recent (late 2007) releases of Open Solaris seem to be adding up to something good.

Более менее дословно:

Что улучшает производительность не очень понятно — естестенно, каждый случай уникальный — но ZFS I/O scheduler, при разработке которого инженеры SUN учитывали его влияние на базы данных, и ZFS багфиксы, которые добавлены в недавний (конец 2007) релиз Open Solaris похоже добавляют что-то хорошее [к производительности].

ZFS I/O scheduler has been shown to make a big difference in performance.

Я так понял:

ZFS I/O scheduler продемонстрирован как сильно влияющий на производительность.

Эх… Мне zfs по этому ролику запомнилось
www.youtube.com/watch?v=CN6iDzesEs0

> С благодарность приму поправки.
[…]
> транзакционной семантикой «копирование по записи»

«по записи» звучит как минимум странно. Устоявшийся перевод термина COW — «копирование при записи». Можно было глянуть хотя бы в ru.wiki/Copy-on-write

Что касается уже не перевода, а сути статьи, то как по мне — маркетинг. У ZFS есть, разумеется, свои преимущества, но проблема double buffering не встречается там, где есть поддержка O_DIRECTIO, а это практически все современные FS, в том числе и Solaris' UFS, которая это тоже давно умеет. Read-ahead можно управлять, по кр. мере в Linux. Из того, с чем действительно сложно не согласиться, это, может быть, чуть более удобное администрирование, но это, скорее, плюс для новичков, поскольку для человека, который проработал с *NIX несколько лет, добавить в /etc/fstab новую запись не проблема вовсе, а если вспомнить о том, что в Linux есть замечательный Software RAID + не менее замечательный менеджер логических дисков (LVM-2), то можно понять, что остаётся не так уж много моментов, в которых действительно возникает желание использовать ZFS (но их есть, да).

Apple отказалась от ZFS в 10.6

Ну что вы я не отказался от MacOS X, мак-мини уже давно подключен телевизору и показывет мне кино.
(это была ирония)

Я написал, что как раз НЕ собирался делать ничего подобного (устанавливать MySQL) с MacOS X, так что факт отказа Apple от ZFS мне безразличен.
Возможно мой кругозор несколько ограничен, но я не вижу никаких причин использовать MySQL на MacOS X.
Если вы знаете о плюсах связки MySQL и MacOS X — поделитесь

«Еще один блоггер из SUN, имеет по крайне мере один тест, в котором ZFS I/O планироващик»

Оригинал: To bring in yet another Sun blogger, there is at least one benchmark where the ZFS I/O scheduler has been shown to make a big difference in performance.

Перевод: Приведем еще одного блоггера Sun, имеется по крайней мере один тест, в котором показано (из которого видно), что планировщик ввода/вывода в ZFS дает большую разницу в производительности.

The real reason for the good performance on this benchmark is not clear — indeed, every workload will be different — but the ZFS I/O scheduler, the Sun engineers paying attention to database performance, and the ZFS bug fixes contributed in recent (late 2007) releases of Open Solaris seem to be adding up to something good.

Настоящая причина хорошей производительности на этом тесте не ясна — на самом деле каждая нагрузка будет разная — но шедулер в/в ZFS (инженеры Sun уделяют внимание производительности базы данных) и исправленные ошибки ZFS в последнее время (конец 2007) в релизе Open Solaris, кажется, дают что-то хорошее.