Исходное сообщение
"Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..." Отправлено Аноним, 20-Авг-12 21:54
>> А какая у него стоимость? > Много памяти, Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок и без немеряного дискового кеша тормозит - ну да. Так ext3 тоже слоупок на фоне ext4, если что. В btrfs это учли. Вообще, ничто не обязывает CoW сам по себе требовать много памяти или тормозить. > много перемещений голов. Сильно зависит от - там запись однократная: пишется только то что изменено. Тогда как журналирующая ФС сделает 2 записи - сначала в журнал, а потом коммит того что в журнале на диск. Мало того что это в 2 раза дольше, так еще и журнал обычно в отдельной области от данных и головы полетят туда через весь диск. Тогда как btrfs например вообще может раскладывать данные как угодно. > Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly. Не скажите. Один из основных козырей - технология имеет потенциал делать запись на диск со скоростью нежурналинуемой ФС при сохранении всех свойств полностью журналирующей. Что довольно здорово само по себе. А как бонус - снапшоты условно нахаляву получаются. > Да и то не всегда, опять же - зависит от паттерна доступа. А вот тут согласен на все 100%. И тем не менее в большинстве бенчей на не засранном томе btrfs вполне культурно выглядит в плане производителности. А хотя-бы на фоне ext4, который вообще никто сроду не юзает в режиме полного журналирования.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> А какая у него стоимость? >> Много памяти, > Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок > и без немеряного дискового кеша тормозит - ну да. Так ext3 > тоже слоупок на фоне ext4, если что. В btrfs это учли. > Вообще, ничто не обязывает CoW сам по себе требовать много памяти > или тормозить. >> много перемещений голов. > Сильно зависит от - там запись однократная: пишется только то что изменено. > Тогда как журналирующая ФС сделает 2 записи - сначала в журнал, > а потом коммит того что в журнале на диск. Мало того > что это в 2 раза дольше, так еще и журнал обычно > в отдельной области от данных и головы полетят туда через весь > диск. Тогда как btrfs например вообще может раскладывать данные как угодно. >> Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly. > Не скажите. Один из основных козырей - технология имеет потенциал делать запись > на диск со скоростью нежурналинуемой ФС при сохранении всех свойств полностью > журналирующей. Что довольно здорово само по себе. А как бонус - > снапшоты условно нахаляву получаются. >> Да и то не всегда, опять же - зависит от паттерна доступа. > А вот тут согласен на все 100%. И тем не менее в > большинстве бенчей на не засранном томе btrfs вполне культурно выглядит в > плане производителности. А хотя-бы на фоне ext4, который вообще никто сроду > не юзает в режиме полного журналирования.
	Введите код, изображенный на картинке: