Исходное сообщение
"Доступна финальная версия ZFS для Linux, работающая на уровн..." Отправлено Anon Y Mous, 01-Фев-11 18:04
> Мне кажется что например хоть вы там оботключайтесь дебаг режимов, но например ZFS даже под своей родной солярой точно так же у фороникса скис в постмарке. Там то уж точно дебага не было. Что как бы намекает что как минимум в дефолтном виде и в их конфигурации ZFS'у "не нравится" данный ворклоад и другие ФС с ним справляются лучше. Настройки по умолчанию бывают разными. Одни по умолчанию настраивают все так, чтобы работало быстрее, пусть и ценой корректности, другие - чтобы работало корректно, пусть и ценой скорости. Вот такая есть интересная заметочка: http://milek.blogspot.com/2010/12/linux-osync-and-write-barr... Если на ZFS'е взять и включить sync=disabled (кстати, фича автором заметки реализована), то postmark будет летать как реактивный. Вот только если пока он летает как реактивный, произойдет пропадалово питания или еще какое аварийное завершение работы, то часть файлов, которые он насоздавал, потеряется. Самой ФС, кстати, ничего не будет - не надо будет ни fsck запускать, ни журнал какой проигрывать... Так что дефолты можно разные настроить. > Впрочем ради справедливости замечу что неудобные ворклоады есть и для других ФС, как например sqlite на btrfs почему-то неважно выступает всегда, независимо от деталей конфигурации. Видимо логика журналирования скулайта плохо дружит с устройством btrfs, как минимум без специальных костылей. Ну это у ребят все впереди - отладка синхронного режима записи так чтобы он работал не только корректно, но и быстро - задача непростая. Кстати, там вроде недавно запилили возможность выноса Log Tree (и других типов метаданных) на отдельные диски (SSD), как в ZFS...

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Мне кажется что например хоть вы там оботключайтесь дебаг режимов, но например ZFS даже под своей родной солярой точно так же у фороникса скис в постмарке. Там то уж точно дебага не было. Что как бы намекает что как минимум в дефолтном виде и в их конфигурации ZFS'у "не нравится" данный ворклоад и другие ФС с ним справляются лучше. > Настройки по умолчанию бывают разными. Одни по умолчанию настраивают все так, чтобы > работало быстрее, пусть и ценой корректности, другие - чтобы работало корректно, > пусть и ценой скорости. Вот такая есть интересная заметочка: http://milek.blogspot.com/2010/12/linux-osync-and-write-barriers.html > Если на ZFS'е взять и включить sync=disabled (кстати, фича автором заметки реализована), > то postmark будет летать как реактивный. Вот только если пока он > летает как реактивный, произойдет пропадалово питания или еще какое аварийное завершение > работы, то часть файлов, которые он насоздавал, потеряется. Самой ФС, кстати, > ничего не будет - не надо будет ни fsck запускать, ни > журнал какой проигрывать... > Так что дефолты можно разные настроить. >> Впрочем ради справедливости замечу что неудобные ворклоады есть и для других ФС, как например sqlite на btrfs почему-то неважно выступает всегда, независимо от деталей конфигурации. Видимо логика журналирования скулайта плохо дружит с устройством btrfs, как минимум без специальных костылей. > Ну это у ребят все впереди - отладка синхронного режима записи так > чтобы он работал не только корректно, но и быстро - задача > непростая. Кстати, там вроде недавно запилили возможность выноса Log Tree (и > других типов метаданных) на отдельные диски (SSD), как в ZFS...
	Введите код, изображенный на картинке: