Представлены (http://www.phoronix.com/scan.php?page=article&item=zfs_fuse_...) результаты сравнения производительности работающей в пространстве пользователя реализации файловой системы ZFS - ZFS-FUSE (0.6.9 и тестовый выпуск 0.7.0) с файловыми системами EXT4 и Btrfs. Сравнение проводилось в установленном по умолчанию дистрибутиве Ubuntu 10.04.1 (x86_64). Дополнительно произведено измерение производительности оригинальной реализации ZFS из состава OpenSolaris b134.
В большинстве тестов ZFS-FUSE сильно отстает от EXT4, Btrfs и оригинальной реализации ZFS, что вызвано замедлением из-за использования механизма FUSE. Реализация ZFS из OpenSolaris на том же оборудовании продемонстрировала близкие с EXT4 и Btrfs показатели, что дает основание предполагать, что нативная реализация ZFS (https://www.opennet.ru/opennews/art.shtml?num=27777) для Linux, работающая в режиме ядра, будет обладать приемлемой производительностью.URL: http://www.phoronix.com/scan.php?page=article&item=zfs_fuse_...
Новость: https://www.opennet.ru/opennews/art.shtml?num=27796
Вот они патенты) В итоге у линуха современная ФС будет очень не скоро...
BTRFS до уровня продакшена еще пилить года три будут, если не больше.
А ZFS уже спокойно можно использовать.
У "линуха" все "ФС" современные. И если ходили по ссылке нативная ZFS по скорости во всех тестах сливает ext4/btrfs.
> У "линуха" все "ФС" современные. И если ходили по ссылке нативная ZFS
> по скорости во всех тестах сливает ext4/btrfs.===
Реализация ZFS из OpenSolaris на том же оборудовании продемонстрировала близкие с EXT4 и Btrfs показатели...
===Коллега не удосужился прочитать текст новости? Напрасно, коллега, напрасно...
В половине тестов ZFS продемонстировала показатели близкие к ZFS-FUSE, что значительно ниже ext4,btrfs...Коллега не удосужился сходить по ссылке? Напрасно, коллега, напрасно...
Хм. Загадочная у вас половина.Единственный тест, в котором ZFS/Solaris была в 24 раза медленнее Линуксовых -- это многопоточная рандомная запись.
Хотя есть ощущение, что тут проблема не в ZFS, а в каких-то других особенностях ядра.
Или таки коллега сам не удосужился сходить по ссылке? Досадно... :)
>Хм. Загадочная у вас половина.
>
>Единственный тест, в котором ZFS/Solaris была в 24 раза медленнее Линуксовых --
>это многопоточная рандомная запись.
>
>Хотя есть ощущение, что тут проблема не в ZFS, а в каких-то
>других особенностях ядра.
>
>Или таки коллега сам не удосужился сходить по ссылке? Досадно... :)Девочки не ссорьтесь, дисковые бенчмарки - лажа.
У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%)Так что, вся жопа в чипсете->проводе->диске.
Все дело в кривых руках
любую конфетку можно испортить кривыми настройками.
>Все дело в кривых руках
>любую конфетку можно испортить кривыми настройками.Причём тут руки, у меня диск ФИЗИЧЕСКИ не умеет быстрее 93 Mb/sec. писать.
Так что, пока выбор только по стабильности.
Юзаю XFS уж лет 7 (с 2.6.0), пока менять не собираюсь.
BTRFS пока сильно грузит проц.
EXT2 - ниайс,
EXT3 - какой-то недоделыш,
EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит.
Reiserfs - хороша, шустра, ставлю на работе и другим, потому что XFS надо настраивать, а так лень :)
JFS - лет 5 назад был тормознее XFS и больше проц, с тех пор забил на неё.
>[оверквотинг удален]
>Так что, пока выбор только по стабильности.
>Юзаю XFS уж лет 7 (с 2.6.0), пока менять не собираюсь.
>BTRFS пока сильно грузит проц.
>EXT2 - ниайс,
>EXT3 - какой-то недоделыш,
>EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит.
>Reiserfs - хороша, шустра, ставлю на работе и другим, потому что XFS
>надо настраивать, а так лень :)
>JFS - лет 5 назад был тормознее XFS и больше проц, с
>тех пор забил на неё.Не обескураживает ли то, что главный пилильщик рейзера, так сказать, отстранен от разработки?)
Ну я про то, что может ext4 юзать вместо рейзера?
> Ну я про то, что может ext4 юзать вместо рейзера?Ну себе я точно пока не буду, а на другие десктопы - пофиг...
почему бы и нет, за одно и потестить на юзерах :)
>Причём тут руки, у меня диск ФИЗИЧЕСКИ не умеет быстрее 93 Mb/sec. писать.Итого: ты забенчил свой диск а не свойства файловых систем. То есть ты попросту облажался. Так и запишем.
>Так что, пока выбор только по стабильности.
А попробуй записать 20 000 мелких файлов и директорий "на холодную" (без кеша) с секундомером. А попробуй потом список файлов из этой кашицы с секундомером? А слить 20Гб чушку? А чтоб еще и торентом? Дабы был множественный параллельный доступ к блокам и фрагментация? А потом тестануть скорость линейного чтения файла - не того? Вот если что-то в таком духе проделать - начнет приходить понимание того что не все йогурты одинаково полезны.
>Юзаю XFS уж лет 7 (с 2.6.0), пока менять не собираюсь.Неплохая ФС, но некоторые операции с большим числом файлов там тормозные. Алсо гугл помнит наезды про забитие нулями файлов при крахе. Из плюсов - хорошо работает с большими файлами, параллелится на многодисковые конфиги на ура, не склонна к фрагментации, но по иронии до кучи есть дефрагер. Мне он ни разу не требовался, но он есть. Парни из SGI задали фрагментации жару :).
>BTRFS пока сильно грузит проц.
Ну так его пока еще даже стабильным не объявили.
>EXT2 - ниайс,
Выбор любителей окаменелостей. Хотя на флешке в принципе как замена FAT читаемая под оффтопиком - сойдет.
>EXT3 - какой-то недоделыш,
Тормозной. Зато надежный и утилиты для починки упорные - до последнего пыжатся том починить. Там где остальные загибаются, оно может даже что-то отколупать. Избавив вас от копания с хексэдитором и photorec если бэкапа не оказалось. В остальном то же что и ext2.
>EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит.
Вполне себе катит. Оно резвее XFS на некоторых операциях. На однодисковых конфигах оно ему особо не уступит. Вообще приятная и резвая ФС, хоть и с архаизмами. И дефрагера нет. Но в целом недурненько.
>Reiserfs - хороша, шустра, ставлю на работе и другим,
Врагам ее надо ставить. Чтоб когда у них порушится том, они понаблюдали как fsck том окончательно угробит вместо починки. Процент таких воплей vs процент юзающих эту фс как-то не вкусный. ФС для тех у кого есть регулярные бэкапы и упсина.
> потому что XFS л надо настраивать, а так лень :)
Даже с настройкой некоторые операции с файлами у него довольно тормозные.И, кстати при некоторых операциях XFS не дурак погрузить проц.
>JFS - лет 5 назад был тормознее XFS и больше проц,Ни рыба ни мясо. Проц жрет меньше XFS имхо. Но и работает не особо резво. При наличии ext4 и xfs - смысла в нем не так уж много. Просто средненькая такая ФС. Пусть будет, может кому понравится как альтернатива упомянутым при некоторых нагрузках.
>с тех пор забил на неё.
Мало что потерял наверное.
>>Причём тут руки, у меня диск ФИЗИЧЕСКИ не умеет быстрее 93 Mb/sec. писать.
>
>Итого: ты забенчил свой диск а не свойства файловых систем. То есть
>ты попросту облажался. Так и запишем.На, пиши...
# iozone -a -b bench.xls -+u -p -B -e -E
>
>>Так что, пока выбор только по стабильности.
>
>А попробуй записать 20 000 мелких файлов и директорий "на холодную" (без
>кеша) с секундомером.Дочитай все сообщения до конца.
> А попробуй потом список файлов из этой кашицы с секундомером? А слить 20Гб чушку?
> А чтоб еще и торентом? Дабы был множественный параллельный доступ к блокам и
> фрагментация? А потом тестануть скорость линейного чтения файла - не того?
> Вот если что-то в таком духе проделать - начнет приходить понимание того что
> не все йогурты одинаково полезны.При таких мутациях, на одной и тоже FS, или даже на одном и том же компе,
Вы сами дважды не повторите результат. Даже с погрешностями в измерениях.Кстати, запись и тем более чтение торрента, можно приравнять к RANDOM R/W.
>На, пиши...
># iozone -a -b bench.xls -+u -p -B -e -EИ? Если в тестах всех фс получается одинаковое значение - значит ты протестил что угодно кроме поведения ФС при нагрузке. У разных алгоритмов - разные свойства. Ты хочешь доказать обратное? Тогда докажи математически что O(N) == O(log N) == O (1) чтоли. Или с фига ли список файлов линейным списком будет столь же быстр как b-дерево, например? Туда же и битовые карты vs экстенты и прочая.
>Вы сами дважды не повторите результат. Даже с погрешностями в измерениях.
Да, для торента это и правда будет сделать крайне сложно (придется сгородить целый тестлаб). В таком случае можно собрать усредненную статистику, так что выпады в ту или иную сторону в единичных случаях будут мало влиять, а вот свойства ФС в целом - неизбежно проявятся.
>Кстати, запись и тем более чтение торрента, можно приравнять к RANDOM R/W.
Не совсем так. Сильно зависит от торент-клиента и его стратегии поведения и настроек. Они разные бывают. Кто-то преаллоцирует файлы целиком, а кто-то - нет. Кто-то делает упреждающее чтение, а кто-то нет. Кто-то буферит получаемые блоки так, а кто-то эдак. Но в целом торент является очень забавным методом посмотреть как ФС ведет себя в тяжелых случаях. К слову, так можно подгадить даже XFS, хоть он и могуче сопротивляется фрагментации.
>>EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит.
>
>Вполне себе катит. Оно резвее XFS на некоторых операциях. На однодисковых конфигах
>оно ему особо не уступит. Вообще приятная и резвая ФС, хоть
>и с архаизмами. И дефрагера нет. Но в целом недурненько.дефрагер таки есть e4defrag
>любую конфетку можно испортить кривыми настройками.Тогда скажите, о Гуру, что мне сделать чтобы FAT32 стал позволять файлы более 4Гб и перестал тормозить на директориях с тысячами файлов. Сменить ФС - не предлагать.
Хинт: кроме рук у ФС есть сильные и слабые стороны еще. Вытекающие из особенностей дисковых структур конкретных ФС.
подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов в директории?
и что бы попытка сделать cd или readdir в такой директории не заканчивалась большими тормозами ?
> подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов в директории?Сконвертировать ее в ext4.
> и что бы попытка сделать cd или readdir в такой директории не заканчивалась большими тормозами ?проверь чтобы -O dir_index было включено (man tune2fs) (после включения возможно надо скопировать файлы в дир снова, не знаю)
Ничего копировать не надо - можно прогнать fsck с оптимизацией директорий. В зависимости от условий эксплуатации.
>подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов
>в директории?
>и что бы попытка сделать cd или readdir в такой директории не
>заканчивалась большими тормозами ?Ultra320 SCSI
SAS/SAS II
в первых двух диски на 15000 об.,
SSD SLC
Внешний PCI-X SATA II контроллер с кэшем поболее.
RAID5 замутить
>подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов
>в директории?
>и что бы попытка сделать cd или readdir в такой директории не
>заканчивалась большими тормозами ?/opt/test # for i in `seq 1 300000`; do echo $i > $i; done;
/opt/test # cd /
/ # time cd /opt/test; time ls | wc -l ; time stat * > /dev/null; cd /real 0m0.000s
user 0m0.000s
sys 0m0.000s
300000real 0m1.425s
user 0m0.671s
sys 0m0.106sreal 0m14.958s
user 0m9.259s
sys 0m4.918s
>>подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов
>>в директории?
>>и что бы попытка сделать cd или readdir в такой директории не
>>заканчивалась большими тормозами ?
>
>/opt/test # for i in `seq 1 300000`; do echo $i > $i; done;Ой, я случайно 300.000 написал :)
----------
# hdparm -i /dev/sda
Kingston SSDNow V Series 64GB, FwRev=B090522a
# cat /proc/mounts | grep root
/dev/root / xfs rw,delaylog,nodev,noatime,nodiratime,attr2,noquota 0 0
> /dev/root / xfs rw,delaylog,nodev,noatime,nodiratime,attr2,noquota 0 0~~~
Читер detected. :)
fullfat или fastfat использовать
>>любую конфетку можно испортить кривыми настройками.
>
>Тогда скажите, о Гуру, что мне сделать чтобы FAT32 стал позволять файлы
>более 4Гб и перестал тормозить на директориях с тысячами файлов. Сменить
>ФС - не предлагать.exFat http://ru.wikipedia.org/wiki/ExFAT
>У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%)А что ты бенчишь? А то если бенчить чтение RAW девайса то там наверное тоже будет что-то типа 93 мб/сек. Кстати при чтении raw девайса почему-то вообще не важно какая там ФС, скорость почему-то одинаковая. Я что-то делаю не так? :)
>>У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%)
>
>А что ты бенчишь? А то если бенчить чтение RAW девайса то
>там наверное тоже будет что-то типа 93 мб/сек. Кстати при чтении
>raw девайса почему-то вообще не важно какая там ФС, скорость почему-то
>одинаковая. Я что-то делаю не так? :)Ой, перепутал не bonnie++, IOZone канешна..
Строка запуска такая: iozone -a -b bench.xls -+u -p -B -e -E
>У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%)Я вообще плохо понимаю, чего она выдает. :D Юзаю iozone.
>> У "линуха" все "ФС" современные. И если ходили по ссылке нативная ZFS
>> по скорости во всех тестах сливает ext4/btrfs.
>
>===
>Реализация ZFS из OpenSolaris на том же оборудовании продемонстрировала близкие с
>EXT4 и Btrfs показатели...
>===
>
>Коллега не удосужился прочитать текст новости? Напрасно, коллега, напрасно...а если бы коллега посмотрел на первоисточник он бы увидел что нативный солярисный zfs во многих тестах сливает btrfs в 2-3 раз и ext4 в 10+ раз, и только в некотрых на равне с btrfs, кроме теста PostgreSQL где выигрывает в 2 раза у бтрфс и сильно проигрывает ext4
зы: лично для меня это как-то странно, зфс вроде пилили долго и упорно, неужели почти все усилия ушли в удобство организации дискового пространства а не в быстродействие ?
>зфс вроде пилили долго и упорно, неужели почти все усилия ушли в удобство организации дискового пространства а не в быстродействие ?Похоже на то, что в кое-чьем представлении enterprise - это прежде всего админы с квалификацией не выше эникейщика, для которых надо все упрощать.
А высокие скорости, высокие нагрузки, быстрое восстановление после сбоя - все это как бы не имеет ничего общего с enterprise.
>>зфс вроде пилили долго и упорно, неужели почти все усилия ушли в удобство организации дискового пространства а не в быстродействие ?
>
>Похоже на то, что в кое-чьем представлении enterprise - это прежде всего
>админы с квалификацией не выше эникейщика, для которых надо все упрощать.Ваши намеки неясны, а логика туманна.
Озвучьте замысел слов ваших.>А высокие скорости, высокие нагрузки, быстрое восстановление после сбоя - все это
>как бы не имеет ничего общего с enterprise.- высокие скорости,
- высокие нагрузки,
- быстрое восстановление после сбояСудя по графикам, сейчас ZFS может выдавать любые 2 из трех.
Собственно, поэтому комрад и задал вопрос)
>а если бы коллега посмотрел на первоисточник он бы увидел что нативный
>солярисный zfs во многих тестах сливает btrfs в 2-3 разТак. Смотрим ещё раз в Фороникс (данные приведены для пары BtrFS:Solaris ZFS):
546,42 : 1296,20 (чем больше, тем лучше)
2110,0 : 660,0 (чем больше, тем лучше)
12,02 : 11,78 (чем меньше, тем лучше)
99,58 : 102,63 (чем больше, тем лучше)
128,97 : ниже погрешности измерений (чем больше, тем лучше)Итого: ZFS показывает БОЛЬШУЮ, чем BtrFS, производительность в ТРЁХ случаях, и МЕНЬШУЮ -- в двух. При, заметим, СУЩЕСТВЕННО меньшей нагрузке на микропроцессор.
И вот откуда вы взяли своё утверждение? Ну вот откуда? Монитор барахлит?
а нахига так место по-ниже спины то рвать?
есть какой-то интерес? в альтруизме вы вроде не замечены были.
ps:
не забываем, вся эта бодяга проходит на SSD.
где экспериментальный бтр по-жизни сливал. при этом zfs должен (по анонсам) порвать всех.
а в результате - zfs показывает ведёт себя как генератор случайных чисел.
в последнем тесте вообще не отдуплился.
вывод: для файлопомоек - мэй би.
для всего остального - лучше уж пусть старым, дедовским, но проверенным способом.
> а нахига так место по-ниже спины то рвать?
> есть какой-то интерес? в альтруизме вы вроде не замечены были.Есть. Заткнуть рты особо "хитро читающим". Просто достаёт "журнализм". Берём данные, и делаем из них нужные нам выводы. Меня это раздражает. ;)
> не забываем, вся эта бодяга проходит на SSD.
> где экспериментальный бтр по-жизни сливал. при этом zfs должен (по анонсам) порвать
> всех.Йопта. Ещё один специалист по ZFS.
ZFS с SSD работает нормально только тогда, когда на SSD лежит строго одна вещь -- ZFS Intent Log. ZIL. ZIL! А не данные! Вы ж поймите, что SSD на _переписывание_ работает достаточно медленно -- to prevent cell wearing-out. А ZFS переписывать любит. При _дописывании_ блока в конец файла _переписывается_ предпоследний.
> вывод: для файлопомоек - мэй би.
О, да. Особенно после теста с pgBench'ем. ;)
> для всего остального - лучше уж пусть старым, дедовским, но проверенным способом.
Да это-то завсегда пожалуйста. Хоть лавсановую перфоленту муравьиной кислотой травите. ;)
Скажите уж честно: вас достает то что в вашей бзде нету ext4 и btrfs. Вот вы и носитесь с ZFS как с писаной торбой. Больше выбирать все-равно не из чего. В итоге приходится скатываться к задоприкрывательским формулировкам вида "Берём данные, и делаем из них нужные нам выводы. Меня это раздражает. ;)". Дескать, это все заговор фороникса и вообще данные не те. Вот такое жопоприкрывательство вместо признания слабых мест конкретной ФС - раздражает. Потому что игнорируется что в мире есть не только ZFS и BSD например и что остальные могут внезапно оказаться лучше.> При _дописывании_ блока в конец файла _переписывается_ предпоследний.
Это как? По идее copy-on-write должен записать блок в сторонку а старый вообще не трогать. Или как потом к снапшоту например со старой версией файла откатываться если блок с этими данными уже перезаписан и возврата нет?
> Дескать, это все заговор форониксаДа в том то и дело, что Phoronix приводит довольно адекватные данные.
А вот комментаторы с OpenNet'а их... э-э-э-э-э-э... несколько вольно интерпретируют. :)
>и вообще данные не те. Вот такое жопоприкрывательство вместо признания слабых
>мест конкретной ФС - раздражает. Потому что игнорируется что в мире
>есть не только ZFS и BSD например и что остальные могут
>внезапно оказаться лучше.Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким образом, чтобы они удовлетворяли их ожиданиям. Почти Dag-Erling Coodan Smorgrav. :)
>> При _дописывании_ блока в конец файла _переписывается_ предпоследний.
>Это как? По идее copy-on-write должен записать блок в сторонку а старый
>вообще не трогать. Или как потом к снапшоту например со старой
>версией файла откатываться если блок с этими данными уже перезаписан и
>возврата нет?Почитайте, как устроен ZFS. При записи блока контрольная сумма его записывается в предыдущий в цепочке -- это исключает появление ошибок в файлах при сбоях в адресации дискового пространства.
>Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким образомименно.
поэтому не понятен ваш предвзятый вывод - "zfs прекрасна в своём торможении".кстати, вы это другим специалистам рассказывайте, а факт - осёл (мир его праху) с zfs требует в минимале 768мб; писибсд - 1гб.
и вы можете сколько угодно говорить о "прямых" (но не очень чистых) руках, этот факт сие не изменит.
> кстати, вы это другим специалистам рассказывайте, а факт - осёл (мир его праху)
> с zfs требует в минимале 768мб;Да вы что?
OpenSolaris OS native install: 512 MB minimum
Только что прочитал на присланном когда-то Sun'ом фирменном диске с OpenSolaris'ом.
Ну как же достали "специалисты" с OpenNet'а...
>OpenSolaris OS native install: 512 MB minimumКак-то оно конечно работать будет, но если воткнуть ZFS на машину с 512 мегов, забенчить и сравнить с ext4, btrfs или чем там еще на этой конфиге - вы будете опять верещать про то что дескать конфиг хреновый, руки кривые и вообще все п-сы. Потому что на машине с 512 мегами ZFS вообще ничего такого не сможет показать.
Так.Было утверждение: OpenSolaris требует минимум 768 мегабайт ОЗУ.
Было опровержение: Sun Microsystems пишет, что он требует 512 мегабайт.Разговор про бенчмарки вообще шёл?
конечно.
тут вообще вся новость про бенчмарки.
и рекомендуемое озу таки 768. особенно с дев.
хотя это уже и не важно. сдох бобик.
> конечно.
> тут вообще вся новость про бенчмарки.Но thread не только о них.
> и рекомендуемое озу таки 768. особенно с дев.
Именно. Однако, обратимся к посту, на который я отвечал:
===
кстати, вы это другим специалистам рассказывайте, а факт - осёл (мир его праху) с zfs требует в минимале 768мб;
===Вам фореграундом по бэкграунду написали -- "требует в минимале". Вот я и написал, сколько OpenSolaris ДЕЙСТВИТЕЛЬНО требует в минимальной конфигурации.
А вы с пеной у рта пытаетесь защищать человека, который облажался. ;)
глупости. с пеной у рта тут только вы.
вам нравится? используйте. чё раскричались то?
мне - нет. мне вообще не нравятся фс с сомнительной перспективой, тормозящие и требующие эндцать мегов (гигов) озу только для себя любимой.
>Так.
>
>Было утверждение: OpenSolaris требует минимум 768 мегабайт ОЗУ.
>Было опровержение: Sun Microsystems пишет, что он требует 512 мегабайт.И чё? Вон каноникал пишет что для убунты 256 метров хватит. Давайте не путать минимальные требования с рекомендованными.
>Разговор про бенчмарки вообще шёл?
<К.0.>Ну типа новость о них</K.0>
>Да в том то и дело, что Phoronix приводит довольно адекватные данные.И по ним видно что под рядом нагрузок ZFS сливается. В то время как EXT4 с честью держит большинство нагрузок. И btrfs ряд нагрузок держит лучше. Может быть, дело в том что блочное выделение места вместо экстентов было модно в прошлом веке?
>А вот комментаторы с OpenNet'а их... э-э-э-э-э-э... несколько вольно интерпретируют. :)
Вы главное в своем глазу бревно не забудьте.
>Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким
>образом, чтобы они удовлетворяли их ожиданиям. Почти Dag-Erling Coodan Smorgrav. :)Ну знаете, если в threaded бенче zfs показывает 5 мегов в секунду, сливая и ext4 и btrfs в десятки раз - epic fail дизайна фс под такой нагрузкой - очевиден. Видать нагрузка неудобная оказалась. Наверное потому и рекомендуют гигазы оперативы под буфера - чтобы косяки дизайна фс немеряными буферами вытягивать.
>Почитайте, как устроен ZFS. При записи блока контрольная сумма его записывается в
>предыдущий в цепочке -- это исключает появление ошибок в файлах при
>сбоях в адресации дискового пространства.В какой из док это в таком виде написано? URL? Какие-то странные сведения и странная операция: перезапись - это всегда шанс угробить данные в перезаписываемом блоке. Зачем трогать лишний раз старые блоки, если в таком дизайне ФС они могут потребоваться потом? Вроде ж идея copy-on-write как раз в том чтобы старые данные лишний раз не трогать?!
>>Да в том то и дело, что Phoronix приводит довольно адекватные данные.
>И по ним видно что под рядом нагрузок ZFS сливается. В то
>время как EXT4 с честью держит большинство нагрузок. И btrfs ряд
>нагрузок держит лучше. Может быть, дело в том что блочное выделение
>места вместо экстентов было модно в прошлом веке?Ну да. Под частью нагрузок сливается один дизайн FS, под частью -- другой. А Ext4 вообще doesn't count -- или ответьте на мой вопрос чуть выше по thread'у про распределение нагрузки по пулу.
>>А вот комментаторы с OpenNet'а их... э-э-э-э-э-э... несколько вольно интерпретируют. :)
>Вы главное в своем глазу бревно не забудьте.А вы на личности-то не переходите. Я конкретно вам никаких высказываний не адресовал. И помните -- Argumentum ad Hominem -- признанный Epic Fail в полемике. ;)
>>Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким
>>образом, чтобы они удовлетворяли их ожиданиям. Почти Dag-Erling Coodan Smorgrav. :)
>Ну знаете, если в threaded бенче zfs показывает 5 мегов в секунду,
>сливая и ext4 и btrfs в десятки раз - epic fail
>дизайна фс под такой нагрузкой - очевиден. Видать нагрузка неудобная оказалась.
>Наверное потому и рекомендуют гигазы оперативы под буфера - чтобы косяки
>дизайна фс немеряными буферами вытягивать.А вот вам бы я посоветовал дочитать статью на Форониксе до конца. Авторы пишут, что есть подозрение, что это Bottleneck in Nevada Kernel.
>>Почитайте, как устроен ZFS. При записи блока контрольная сумма его записывается в
>>предыдущий в цепочке -- это исключает появление ошибок в файлах при
>>сбоях в адресации дискового пространства.
>В какой из док это в таком виде написано? URL? Какие-то странные
>сведения и странная операция: перезапись - это всегда шанс угробить данные
>в перезаписываемом блоке. Зачем трогать лишний раз старые блоки, если в
>таком дизайне ФС они могут потребоваться потом? Вроде ж идея copy-on-write
>как раз в том чтобы старые данные лишний раз не трогать?!Охъ. В ZFS Design Guide это написано. На Sun Tech Days сто раз говорилось.
>На Sun Tech Days сто раз говорилось.Я уже по вашим запощенным новостям понял что вы "солярщик", и весь смысл вашей активности заключается в принижение linux и возвышение за счет этого "солярки".
> Я уже по вашим запощенным новостям понял что вы "солярщик", и весь
> смысл вашей активности заключается в принижение linux и возвышение за счет
> этого "солярки".Я так понимаю, что напал на "красноглазого". ;)
Объясняю в 121'й раз: мне совершенно наплевать, как называется технология -- UNIX, Windows, VxWorks, или как либо ещё. Мне совершенно наплевать, кто и как эту технологию разрабатывает -- open source она, не open, GPL, BSD, APL, MPL или любой другой лицензии.
И когда люди начинают сравнивать технологии не с позиций цифр в тестах (а я специально трижды перечитал статью с Фороникса и выписал с неё цифры тестов нативных технологий, а не костылей, типа FUSE/etc.), а с позиций того, кто _автор_ технологии, и её _лицензии_ -- меня это приводит в состояние кататонического ступора и когнитивного диссонанса одновременно. :)
Ну ведь ёжику понятно, что если Ext4 повесить поверх LVM'а, а в ZFS выключить подсчёт контрольных сумм (чтобы скомпенсировать overhead'ы), то ZFS надерёт Ext4 задницу по полной программе за счёт агрессивного кеширования.
Но! "One can be arbitrarily fast if data integrity isn't a question". (C) ZFS Evil Tuning Guide. Поэтому сравнивать Ext4 и ZFS -- это сравнивать автомобиль с самолётом. В ZFS есть сквозная data integrity, в Ext4 -- нет и не предвидится. Поэтому сравнение здесь непоказательно.
А данные по сравнению BtrFS и ZFS я привёл в самом начале thread'а -- сравнение, увы, не в пользу BtrFS. ;)
И линуксячьи хомячки могут хоть на пузе извертеться -- всё равно не в пользу. ;)
>> Я уже по вашим запощенным новостям понял что вы "солярщик", и весь
>> смысл вашей активности заключается в принижение linux и возвышение за счет
>> этого "солярки".
>
>Я так понимаю, что напал на "красноглазого". ;)Отлично, надо объявить опонента красноглазым, это оправдает свой фанатизм.
>Объясняю в 121'й раз: мне совершенно наплевать, как называется технология -- UNIX,
>Windows, VxWorks, или как либо ещё. Мне совершенно наплевать, кто и
>как эту технологию разрабатывает -- open source она, не open, GPL,
>BSD, APL, MPL или любой другой лицензии.что ты делаешь на этом ресурсе?
>И когда люди начинают сравнивать технологии не с позиций цифр в тестах
>(а я специально трижды перечитал статью с Фороникса и выписал с
>неё цифры тестов нативных технологий, а не костылей, типа FUSE/etc.), а
>с позиций того, кто _автор_ технологии, и её _лицензии_ -- меня
>это приводит в состояние кататонического ступора и когнитивного диссонанса одновременно. :)Однако забыл выписать цифры с ext4, видимо из-за когнитивного диссонаса.
>Ну ведь ёжику понятно, что если Ext4 повесить поверх LVM'а, а в
>ZFS выключить подсчёт контрольных сумм (чтобы скомпенсировать overhead'ы), то ZFS надерёт
>Ext4 задницу по полной программе за счёт агрессивного кеширования.Если танк доработать напильником то получится самолет и то не факт.
>Но! "One can be arbitrarily fast if data integrity isn't a question".
>(C) ZFS Evil Tuning Guide. Поэтому сравнивать Ext4 и ZFS --
>это сравнивать автомобиль с самолётом. В ZFS есть сквозная data integrity,
>в Ext4 -- нет и не предвидится. Поэтому сравнение здесь непоказательно.Да да, побольше английского, ничего на сказав вы можете получить эффект что ваш опонент испугается и убежит.
>
>А данные по сравнению BtrFS и ZFS я привёл в самом начале
>thread'а -- сравнение, увы, не в пользу BtrFS. ;)да ну?
>И линуксячьи хомячки могут хоть на пузе извертеться -- всё равно не
>в пользу. ;)Откровено ведь грубите.
>Отлично, надо объявить опонента красноглазым, это оправдает свой фанатизм.Слово "солярщик" первым употребили именно вы.
>что ты делаешь на этом ресурсе?
Я вот всегда думал, что опеннет - прежде всего для инженеров. А уж какие у них убеждения в глубине души - это второй вопрос. До тех пор, пока они не обсуждают здесь оффтопик, все хорошо. Или я неправ?
>Да да, побольше английского, ничего на сказав вы можете получить эффект что
>ваш опонент испугается и убежит.Если у вас проблемы с чтением английского, воспользуйтесь Google Translate. Инженерам, которые работают в области IT, без знания английского делать в отрасли нечего. А та английская фраза, которую он привел, вполне себе в тему.
>>И линуксячьи хомячки могут хоть на пузе извертеться -- всё равно не
>>в пользу. ;)
>
>Откровено ведь грубите.Кому как. Лично я бы предпочел срач с Луговским с его незабвенным "удавись, мразь" в свой адрес любой другой беседе с дураком, который меня будет называть "милостивый государь" и во всем со мной соглашаться. Первое как-то информативнее.
>Ну да. Под частью нагрузок сливается один дизайн FS, под частью -- другой.И что характерно - схемы с экстентами в целом работают лучше чем схемы с поблочным выделением. Загнать в ж можно любую, но варианты с экстентами более жопоупорны. Поэтому практически все фс новой разработки используют экстенты. Кстати они есть в ext4 и в btrfs но их нет в zfs. Может быть это одна из причин ее тормознутости в ряде бенчей?
>А Ext4 вообще doesn't count -- или ответьте на мой
>вопрос чуть выше по thread'у про распределение нагрузки по пулу.А мозг включить и подумать? Распределением нагрузки на несколько дисков может заниматься как сама ФС так и иной слой под ней, например. И в линухе есть где развернуться на этот счет. Да, может это и менее удобно, но вполне реализуемо в случае если оно надо. Странно что такая простая истина так трудно доходит.
>А вы на личности-то не переходите.
Не буду. Но если кто-то тормозит - я в своем праве отметить этот факт.
>А вот вам бы я посоветовал дочитать статью на Форониксе до конца.
>Авторы пишут, что есть подозрение, что это Bottleneck in Nevada Kernel.Ага, а если взять бсд - при сливе начнуть бухтеть что фс в системе без году неделя и еще не отлажена. Что ж тогда брать то? Сферический zfs в вакууме? И вообще, zfs у самого по себе bottleneck-ов найдется. Загнать его в Ж с его блочной аллокацией вообще судя по всему ни проблема ни разу.
>Охъ. В ZFS Design Guide это написано. На Sun Tech Days сто
>раз говорилось.Почитаю, перепроверю. Странное какое-то решение - лишний раз блоки данных трогать.
>а в результате - zfs показывает ведёт себя как генератор случайных чисел.
>
>в последнем тесте вообще не отдуплился.
>вывод: для файлопомоек - мэй би.
>для всего остального - лучше уж пусть старым, дедовским, но проверенным способом.Неплохо ведет ZFS raid1 в работе с nginx+php+php-fpm+Mysql
Юзеры сидят, работают и не жужжат.
дык как обычно.
пусть ещё только попробуют пожужжать.
>Неплохо ведет ZFS raid1 в работе с nginx+php+php-fpm+MysqlА сравнивалось с чем? Ни с чем, как обычно? Ну так это неинтересно тогда. Я тоже могу что-то сгородить и вещать как это хорошо. Вот только большой вопрос как мое решение будет в сравнении с другими. А так сабжевую связку может запустить даже неглупый школьник. А вот грамотно выбрать решение из всего арсенала имеющихся так чтобы оно оптимально вписалось в задачу - школьник уже не сможет.
ну типа тестов больше чем пять, и есть еще ext4 про которую вы умалчиваете.
> ну типа тестов больше чем пятьВ остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные).
> и есть еще ext4 про которую вы умалчиваете.
Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4 _ничего_ не умеет.
В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode File System. Так она по производительности вообще всех рвала в тряпки. ;) Можете поковыряться и посмотреть, что это было. ;)
>В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные).Свинство, факт.
>Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4
>_ничего_ не умеет.А ничего что в Linux нужные слои типа райдов и управления томами - есть? При необходимости ext4 начинает уметь и райды и добавление томов в пул. Менее изящно но вполне работает.
>В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode
>File System. Так она по производительности вообще всех рвала в тряпки.
>;) Можете поковыряться и посмотреть, что это было. ;)Кому-то нужны лулзы, а кому-то работать. С линухом работать приятнее - там всегда под задачу есть что выбрать. А бздуны выбирают из ZFS и UFS, при том первый очень не любит некоторые типы нагрузок, характерных для серверов а второе - ископаемое. Итого - zfs может претендовать на сильно некоторые файлопомойки. Если оракль патентами размахивать не начнет.
>> В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные).
> Свинство, факт.Или из страха?-)
>> Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4
>> _ничего_ не умеет.
> А ничего что в Linux нужные слои типа райдов и управления томами
> - есть? При необходимости ext4 начинает уметь и райды и добавление
> томов в пул. Менее изящно но вполне работает.Да? Ext4 может распараллеливать нагрузку между пятью дисками в пуле? Ext4 может сказать об этом другим слоям?
> Итого - zfs может претендовать на сильно некоторые файлопомойки.
Победив в pgBench'е. Чудесная логика. Вы файлы в BLOB'ах держать предлагаете?-)
>Или из страха?-)угу. кольчугина испугались.
>Победив в pgBench'е. Чудесная логика. Вы файлы в BLOB'ах держать предлагаете?-)не иначе - результат испуга
А вы не сливайтесь, не сливайтесь. :) Я не кусаюсь. :)Так что, может ваша хвалёная Ext4 распределять нагрузку по пяти дискам пула?-) Или хотя бы сказать об этом соответствующему Layer'у?-)
>Так что, может ваша хвалёная Ext4 распределять нагрузку по пяти дискам пула?-)Сама по себе она конечно этого не умеет. Однако можно ведь собрать скажем страйп из 5 дисков и тогда при достаточной интенсивности операций с файлами, особенно если это большие объемы или несколько потоков - доступ будет размазан на все диски. Сами догадайтесь почему. Эффективность по скорости будет не сильно хуже иных вариантов. А какая дискам разница кто там на одновременно читаемые/записываемые блоки попилил - уровень ФС или тот кто изображает райд?
>Или хотя бы сказать об этом соответствующему Layer'у?-)
А тут все зависит от целей. Если цель - решить задачу то есть 1000 возможностей. А если цель встать в позу и сказать "фи, гадость" - есть 1000 отговорок. Вам видимо важнее второе.
Нет, друг мой, stripe -- это плохо. И вот почему.Вы себе представляете работу с дисковым массивом таким образом: системный администратор берёт хрустальный шар, внимательно смотрит в него, и в его голове автоматически появляются сведения, где ему нужно приобрести пять одинаковых (для stripe это важно!) дисков, и какого они должны быть объёма.
Не подскажете ли, у кого можно такой хрустальный шар на время одолжить?-) У меня есть несколько вещей, которые мне срочно надо узнать. ;)
А на самом деле всё происходит совсем не так. У нас есть дисковая полка (или сервер с местом под 8..16 HDD). Мы в него вставляем 3 диска. Делаем RAIDZ. Оно у нас живёт. Кончается дисковое место -- мы вставляем ещё 3 диска (возможно, другого объёма, чем первые три -- диски-то совершенствуются!) Понятное дело, что некоторое первое время они практически не загружены -- но ZFS постепенно "размазывает" данные на наши шесть дисков. Причём не поровну, а так, чтобы сбалансировать I/O по всем каналам (она же на всех уровнях присутствует, эта ZFS, так что знает, на какой физический канал контроллера сколько пишется). И плевать, что у дисков геометрия разная, что скорость работы разная... Всё равно результат будет правильным.
Кончились? Что ж, давайте ещё троечку добавим... ;)
Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно там) такое?
> Делаем RAIDZ.Или mirror, или просто тома. Это неважно. RAIDZ -- это я так, чтобы надёжность хранения была.
>Нет, друг мой, stripe -- это плохо. И вот почему.
>
>Вы себе представляете работу с дисковым массивом таким образом: системный администратор берёт
>хрустальный шар, внимательно смотрит в него, и в его голове автоматически
>появляются сведения, где ему нужно приобрести пять одинаковых (для stripe это
>важно!) дисков, и какого они должны быть объёма.как связан размер страйпа и размер диска? Расскажите уж нам?
> как связан размер страйпа и размер диска? Расскажите уж нам?URL на производителя контроллера, который может сделать stripe на диски с разными объёмами, не потеряв при этом ни байта, покажите уж нам?
>> как связан размер страйпа и размер диска? Расскажите уж нам?
>
>URL на производителя контроллера, который может сделать stripe на диски с разными
>объёмами, не потеряв при этом ни байта, покажите уж нам?Опа на, и как это связано с:
>где ему нужно приобрести пять одинаковых (для stripe это важно!) дисков, и какого они должны быть объёма.
Путаетесь в показаниях товарищ Эндрю.
> Опа на, и как это связано с:
>> где ему нужно приобрести пять одинаковых (для stripe это важно!) дисков, и какого они
>> должны быть объёма.Напрямую. Вам это неочевидно?
>Напрямую. Вам это неочевидно?Нет. Вы хотите сказать что я не могу сделать raid с дисками 146Гб и 250Гб?
>> как связан размер страйпа и размер диска? Расскажите уж нам?
>
>URL на производителя контроллера, который может сделать stripe на диски с разными
>объёмами, не потеряв при этом ни байта, покажите уж нам?откуда появилось "не потерять ни байта"??? для блочных raid-систем иногда можно пожертвовать 2/3 размера - если важно получить большое кол-во IOPS-ов с LUN-а - мелкие LUN рулят 8-))
и почему вы считаете что при размазывании данных по разным дискам это место потеряется?
Оно может использоваться не оптимально например 8-)
>Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно
>там) такое?умеет, только это называется lvm.
>> Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно
>> там) такое?
> умеет, только это называется lvm.Что умеет LVM? Сообщать файловой системе, в какой части тома теперь модно блоки аллоцировать?
Вы эту дурь больше не курите. Это плохая дурь. :)
это уже не важно.
оппонент почил в бозе. ну и zfs с ним.
Ты бы хоть википедию прочел, хотя бы первые две строчки http://ru.wikipedia.org/wiki/LVM
Прежде чем писать ахинею.
>Вы себе представляете работу с дисковым массивом таким образом: системный администратор берёт
>хрустальный шар, внимательно смотрит в него, и в его голове автоматически
>появляются сведения, где ему нужно приобрести пять одинаковых (для stripe это
>важно!) дисков, и какого они должны быть объёма.Нормальный администратор в общем то может прикинуть решение задачи, избавив всех остальных от баттхерта вида "внезапно кончилось место". Потому что как правило в энтерпрайзе закупка новых комплектующих, особенно серверных - занимает некое время. Достаточно чувствительное. Поэтому да, админы энтерпрайзов должны уметь forward thinking.
>Не подскажете ли, у кого можно такой хрустальный шар на время одолжить?-)
>У меня есть несколько вещей, которые мне срочно надо узнать. ;)Ну, если хрустального шара нет - тогда LVM есть :). В итоге изгалиться - можно. Вариантов комбинирования девайсов и слоев достаточно много. Под задачу всегда можно что-то придумать. Да, может быть будет менее удобно в администреже но - вполне работоспособно.
>А на самом деле всё происходит совсем не так. У нас есть
>дисковая полка (или сервер с местом под 8..16 HDD). Мы в
>него вставляем 3 диска. Делаем RAIDZ. Оно у нас живёт. Кончается
>дисковое место -- мы вставляем ещё 3 диска (возможно, другого объёма,
>чем первые три -- диски-то совершенствуются!)А что помешает сделать примерно то же самое по смыслу средствами LVM например? EXT4 вообще деталей не узнает. Она только сможет отрасти на какимто образом увеличившийся девайс. Может это и менее удобно но вполне работоспособно.
>Понятное дело, что некоторое первое время они практически не загружены
> -- но ZFS постепенно "размазывает" данные>на наши шесть дисков.Я что-то пропустил и в zfs уже сделали возможным сдвигать часть данных существующих файлов на новые диски пула как в бтр? Или это имелось в виду что в процессе работы оно постепенно размажется?
>Всё равно результат будет правильным.
Да, особенно правильным он будет если захотеть диск из пула изъять :). В бтрфс такая ситуация кстати предусмотрена и эта фс может относительно просто и быстро убрать все данные с конкретного диска. А в zfs оно как, сделано уже?
>Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно
>там) такое?А почему бы и нет? Можно нагородить что-то похожее по смыслу скажем через LVM и все что ext4 увидит - девайс отрос и можно увеличить размер ФС, а как оно там внутрях было сделано - вообще не ее проблемы. Менее удобно и возможно менее оптимально, но ничего такого невозможного.
>А вы не сливайтесь, не сливайтесь. :) Я не кусаюсь. :)
>
>Так что, может ваша хвалёная Ext4 распределять нагрузку по пяти дискам пула?-)
>Или хотя бы сказать об этом соответствующему Layer'у?-)Офигеть! С фига ли файловая система по сути структура данных, должна что-то распределять. Этим напрямую занимается планировщик VFS. https://www.opennet.ru/base/sys/linux_vfs.txt.html
Хотя наверное это трудно понять "трушным солярщикам" когда операционка поддерживает более чем одну файловую систему.
> С фига ли файловая система по сути структура данных, должна что-то распределять.Видите ли. Layer Separation имеет свои плюсы и свои минусы.
Такой подход -- с фига ли файловая система должна понимать, на каком media она вообще живёт -- безусловно, имеет право на существование, хотя трушным линуксоидам, как правило, слабо себе представляющим, что внутри белого (или любого другого цвета) ящика, который они называют компьютер, есть масса различных компонентов.Но этот подход -- путь в тупик. :) Мы его один раз уже проходили с UFS: когда-то давно в BSD disklabel и в UFS superblock можно было написать особенности геометрии диска, и UFS старалась писать данные в такие сектора, чтобы минимизировать количество оборотов "тарелки" диска при чтении.
Сейчас эти параметры считаются устаревшими, и современный код UFS в них не смотрит (да и особенности строения винчестеров таковы, что такой параметр, как количество секторов на дорожке, просто бессмыслен, т.к. оно везде разное) -- в результате получаем sub-optimal performance.При разработке ZFS эти грабли учли, и всё-таки решили оптимизировать распределение аллоцируемых блоков на уровне файловой системы. Видимо, на то были причины у инженеров Sun.
>> С фига ли файловая система по сути структура данных, должна что-то распределять.
>
>Видите ли. Layer Separation имеет свои плюсы и свои минусы.
>Такой подход -- с фига ли файловая система должна понимать, на каком
>media она вообще живёт -- безусловно, имеет право на существование, хотя
>трушным линуксоидам, как правило, слабо себе представляющим, что внутри белого (или
>любого другого цвета) ящика, который они называют компьютер, есть масса различных
>компонентов.То есть вы хотите сказать что ваш уровень знаний выше чем у трушных линуксойдов, и все линуксойды сплошь тупые и не знают потроха компьютера?
>Но этот подход -- путь в тупик. :)
Такой тупик что по скорости работы превосходит в десятки раз "нетупиковую" и не гибкую ZFS.
>Мы его один раз
>уже проходили с UFS: когда-то давно в BSD disklabel и в
>UFS superblock можно было написать особенности геометрии диска, и UFS старалась
>писать данные в такие сектора, чтобы минимизировать количество оборотов "тарелки" диска
>при чтении.Имено так всегда отвечайте на вопросы, когда нечего сказать по существу, всегда не в тему, но с кучей умных слов, может быть у ваших опонентов случится переполнение буфера, и вы сойдете за умного.
Когда говорят про линуксовый io планировщик VFS, всегда говорите про бздевый UFS, какая разница что он вообще никак не связан с темой.
>Видите ли. Layer Separation имеет свои плюсы и свои минусы.Поэтому то и есть ext4 и есть btrfs.
>трушным линуксоидам, как правило, слабо себе представляющим, что внутри белого (или
>любого другого цвета) ящика, который они называют компьютер, есть масса различных
>компонентов.Левые набросы. Представлять себе для сбора LVMом желаемой конфиги придется, даже получше любителей zfs-а. Так что толсто - незачет.
>Но этот подход -- путь в тупик. :)
А это только время покажет. Кстати на уровне дизайна в бтрфс больше возможностей для управления томами.
>Мы его один раз уже проходили с UFS: когда-то давно в BSD disklabel и в
>UFS superblock можно было написать особенности геометрии диска, и UFS старалась
>писать данные в такие сектора, чтобы минимизировать количество оборотов "тарелки" диска
>при чтении.Левый бред. EXT4 при юзеже LVM вообще не знает из чего оно там собрано. Все что она видит - некий том. Который может увеличиваться по желанию админа, например. А сколько там девайсов составляют том и как они скомпонованы ФС вообще не знает. Так что вы привели строго инверсный пример. Вы сами себя и оспариваете чтоли? :)
>Сейчас эти параметры считаются устаревшими, и современный код UFS в них не
>смотритА код ext4 не смотрит в то как слеплен девайс LVM. Более того - точную геометрию диска или флешдиска ни одна ФС как вы уже заметили узнать не может. Поэтому performance всегда будет ниже идеала. Просто потому что в большей части случаев ФС не будет владеть информацией достаточной для удачного (для диска) раскладывания структур на дорожки диска (блоки флеша, ...) и будет некоторая неоптимальность. То есть, задача размещения тех же данных скорее всего решаема лучше, но ФС неоткуда про это узнать. Т.к. соответствующей информацией оперирует только контроллер (флеш)диска.
>При разработке ZFS эти грабли учли, и всё-таки решили оптимизировать распределение
>аллоцируемых блоков на уровне файловой системы. Видимо, на то были причины у
>инженеров Sun.Конечно были. У них то не было LVM и они впихали соотв. слой в ФС. Кстати в бтр учли опыт инженеров Sun. И их промахи тоже учли. Сделав так что убирать данные с тома - просто и быстро. Поюзав экстенты, и так далее. Бтр позднее проектировался и потому опыт предшественников в нем учли. Да, прямо сейчас у zfs больше фич, но это вопрос времени. Тем более что оракл вызвал разброд и шатания команд разработчиков своими действиями.
> Кстати на уровне дизайна в бтрфс больше возможностей для управления томами.Например?
>Офигеть! С фига ли файловая система по сути структура данных, должна что-то
>распределять. Этим напрямую занимается планировщик VFS."Планировщик VFS"?! Вот это да! Новое слово в искусстве программирования ядер ОС.
>https://www.opennet.ru/base/sys/linux_vfs.txt.html
Кстати, по этой ссылке нет ни одного слова "планировщик". И гугл проклятый молчит. Может, подскажете, где бы про это почитать поподробнее?
>Хотя наверное это трудно понять "трушным солярщикам" когда операционка поддерживает более чем
>одну файловую систему.Предчувствую, года через два со стороны линуксоидов в дискуссиях будут такие кадры участвовать, что будем с тоской вспоминать о том, как хорошо было беседовать с User294.
>В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode File System.Что-то не припоминаю такого. И гугл молчит, wtf?
Вы не припоминаете -- CVS припомнит. :)))Вот, полюбуйтесь:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ifs/?hidea...
А Google -- а что Google... В 2001'м-то году... ;)
>> ну типа тестов больше чем пять
>
>В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные).или просто таких тестов под солярку нет.
>> и есть еще ext4 про которую вы умалчиваете.
>
>Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4
>_ничего_ не умеет.Давай-давай мори дальше.
>В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode
>File System. Так она по производительности вообще всех рвала в тряпки.
>;) Можете поковыряться и посмотреть, что это было. ;)Вот только ext4 в продакшене, даже гугл на неё перешел.
>>> ну типа тестов больше чем пять
>> В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные).
> или просто таких тестов под солярку нет.Угу. А под Линукс есть (ZFS/FUSE данные есть все).
Конечно-конечно. И gcc в Солярке нет. И /bin/sh. Один CDE сплошной...
>>> и есть еще ext4 про которую вы умалчиваете.
>> Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4
>> _ничего_ не умеет.
> Давай-давай мори дальше.Давать тебе жена будет. Если будет, конечно.
>> В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode
>> File System. Так она по производительности вообще всех рвала в тряпки.
>> ;) Можете поковыряться и посмотреть, что это было. ;)
> Вот только ext4 в продакшене, даже гугл на неё перешел."... даже гугл..." Вот, право, критерий. :)
>>>> ну типа тестов больше чем пять
>>> В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные).
>> или просто таких тестов под солярку нет.
>
>Угу. А под Линукс есть (ZFS/FUSE данные есть все).
>
>Конечно-конечно. И gcc в Солярке нет. И /bin/sh. Один CDE сплошной...У фороникса спроси, чего не сделали.
>> Давай-давай мори дальше.
>
>Давать тебе жена будет. Если будет, конечно.Да неволнуйся ты так право, женат двое детей. Ну а если по теме, что не умеет ext4 по сравнению с zfs?
>>> В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode
>>> File System. Так она по производительности вообще всех рвала в тряпки.
>>> ;) Можете поковыряться и посмотреть, что это было. ;)
>> Вот только ext4 в продакшене, даже гугл на неё перешел.
>
>"... даже гугл..." Вот, право, критерий. :)То есть по твоему over 10 000 000 серверов не критерий, по сравнению с чем-то затерянным в cvs образца 2001 года?
>> Вот только ext4 в продакшене, даже гугл на неё перешел.
>"... даже гугл..." Вот, право, критерий. :)ну конечно, авторитет Кольчугина с дохлой ОС - это куда круче! :D
ps:
>Давать тебе жена будет. Если будет, конечно.вот и основной аргумент - хамство - единственный критерий выбора.
>И вот откуда вы взяли своё утверждение? Ну вот откуда? Монитор барахлит?А можно я вместо того перца отвечу? Открываем http://www.phoronix.com/scan.php?page=article&item=zfs_fuse_... ну и далее.
А там...
0) ZFS-FUSE слил обоим EXT4 и BTRFS в 2 раза на бенче статики опача. Результаты для соляры фороникс почему-то не показал на графике, к сожалению.
1) EXT4 всех порвал на постгресовском TPC-B, в какие-то жалкие 4 раза "всего" :). Btrfs там впрочем тоже не блеснул, но у линуксоидов то есть из чего выбрать. А у остальных систем с zfs выбор разве что из ископаемых UFSов. Наверное дело в том что постгр сам что-то типа версионника и ФС в духе версионника под ним - скорее медвежья услуга чем помощь.
2) В PostMark EXT4 уделал ZFS даже на соляре всего-то в почти 5 раз. Нормально так. Btrfs впрочем тоже сделал ZFSа. Правда "всего" почти в 4 раза. Ну да, он проиграл... ext4-ому.
2.1) В тесте SQLite EXT4 уделал FUSE вариант раза в два, хоть это и малоинформативно за отсутствием результатов для скажем соляры на графике.
3) В unpacking linux kernel все идут нос к носу кроме Fuse варианта ZFS который тормоз. ZFS чуть быстрее EXT4 и нос к носу с BTRFS. Epic win-а как-то не видно. Epic fail FUSE предсказуем.
4) В compile bench EXT4 натянул на 50% btrfs и zfs, которые показали близкие результаты. FUSE вообще где-то в ... ;)
5) В threaded io test ZFS оказался в нереальной опе. Что с fuse, что в родной солярке вообще. BTRFS сделал его в 25 раз :D. EXT4 поскромнее чуток, раз в 15 "всего" :).
6) Собссно небольшой win ZFS виден только в тестах iozone (да, с учетом fuse это достойный упоминания результат, к сожалению для соляры опять не привели цифры)Игого: EXT4 основательно уделывает ZFS под большей частью нагрузок. Btrfs тоже не дурак надрать задницу ZFSу при удобном случае несмотря на сырость. А вот ZFS задницу никому не надирает особо, особенно так чтобы с отрывом в разы. CPU? А что CPU? CPU usage всего что не fuse - не превысил 35% судя по графику.
Выводы: для сегодня EXT4, для завтра btrfs. Fuse можно пользоваться только если позарез приперло прочитать чужой том на не-нативной для него операционке.
> Выводы: для сегодня EXT4, для завтра btrfsДля тех, для кого ничего, кроме Линукса, не существует. Совершенно верно.
А кому надо, чтобы работало, используют человеческие решения.
>Для тех, для кого ничего, кроме Линукса, не существует. Совершенно верно.нука, нука!
и для кого? для бздишнеков? для солярщиков? для маководов?
для кого?
>но у линуксоидов то есть из чего выбрать. А у остальных систем с zfs
>выбор разве что из ископаемых UFSов.Но у линуксоедов Ext4 и тем более Btrfs до сих пор нельзя использовать в продакшене. И выбор ограничен, по-сути, только лишь "ископаемой" Ext3 (которая стала стабильной в 2002-2003гг).
Вывод: Ext4 ещё пилить и пилить; Btrfs ещё сыра как тряпка и не умеет RAID-5; ZFS упирается в многопоточные механизмы ядра и требовательная к памяти; остаётся UFS2 с GEOM (для FreeBSD), которая всех заруливает по адекватности большинства решаемых задач (снапшоты, ACL, RAID-0,-1,-3,-5 модулями GEOM, почти не фрагментируется, не нуждается в журналировании благодаря Soft Updates).
:)UFS2/GEOM уже научилась делать shadowed hierarchy? А delegated administering? А cross-data checksumming? А on-the-fly compression?
Ну хоть "RAID для бедных" -- аналог "copies=n" -- умеет?
Что, так и нет?-) Жа-а-а-а-а-а-а-аль... ;) Так и придётся любителям UFS2/GEOM вечно писать /etc/fstab... ;)
>:)
>
>UFS2/GEOM уже научилась делать shadowed hierarchy?Кэширование каталогов давно работает или WTF, если не так понял.
>А delegated administering?
WTF
>А cross-data checksumming?
WTF
>А on-the-fly compression?
WTF
>Ну хоть "RAID для бедных" -- аналог "copies=n" -- умеет?
WTF
Ну, тогда начнём с изучения научной литературы:http://users.soe.ucsc.edu/~sbrandt/221/zfs_overview.pdf
Там про контрольные суммы и про компрессию. И ещё много про что.
Про DA:
>Ну, тогда начнём с изучения научной литературы:
>
>http://users.soe.ucsc.edu/~sbrandt/221/zfs_overview.pdf
>
>Там про контрольные суммы и про компрессию. И ещё много про что.Я в курсе про сквозную целостность (с заданной степенью расчёта хэша или без) и компрессию на лету (про уровни и алгоритмы тоже в курсе).
>Про DA:
>
>http://lmgtfy.com/?q=zfs+delegated+administrationНа NT-системах это делается мышкой на странице Permissions свойств каталога или её продвинутую страничку со списками (выбрать пользователей, группы — лучше, расставить галочки, нажать кнопку Применить). На ZFS нужно вводить в командной строке определённую строчку. Для UFS2 можно задействовать расширенные атрибуты файлов/каталогов. Ну, и?
>>Про DA:
>>
>>http://lmgtfy.com/?q=zfs+delegated+administration
>
>На NT-системах это делается мышкой на странице Permissions свойств каталога или её
>продвинутую страничку со списками (выбрать пользователей, группы — лучше, расставить галочки,
>нажать кнопку Применить). На ZFS нужно вводить в командной строке определённую
>строчку. Для UFS2 можно задействовать расширенные атрибуты файлов/каталогов. Ну, и?есть мнение, что ты думаешь о чем-то своем, но не о Delegated Administration
>есть мнение, что ты думаешь о чем-то своем, но не о Delegated AdministrationЕсть ещё PAM. Не то?
>> есть мнение, что ты думаешь о чем-то своем, но не о Delegated Administration
> Есть ещё PAM. Не то?Нет, не то.
Очень вкратце, в применимости к FreeBSD: ну например, можно создать jail на некоторой подыерархии ZFS, сказать на эту подыерархию "zfs jail <subhierarchy>", после чего в jail'е можно будет создавать файловые системы-листья этой подыерархии. Суперюзеру, конечно. :) А тако ж ставить квоты, атрибуты "exec/noexec", "setuid/nosetuid", и так далее.
Но в Jail'е. С Солярными зонами ситуация аналогичная, только там "zfs zone".
Вот это и есть delegated administration.
>Но в Jail'е. С Солярными зонами ситуация аналогичная, только там "zfs zone".
>
>
>Вот это и есть delegated administration.До ZFS обходились ФС на виртуальном блочном устройстве (см mdconfig). Просто и дёшево.
P.S.
UFS я всё-таки сравниваю с традиционными ФС, что сейчас на продакшене в Linux. Вывод делаю неутишительный: в Linux до сих пор нет классических надёжных ФС с необходимыми фичами (снапшоты) и способных противостоять разрушению без обращения к отдельным костылям (LVM, журнал транзакций).
никому уже не интересен ВАШ вывод.
вот в чём вопрос.
>Но у линуксоедов Ext4 и тем более Btrfs до сих пор нельзя
>использовать в продакшене. И выбор ограничен, по-сути, только лишь "ископаемой" Ext3
>(которая стала стабильной в 2002-2003гг).сказал бздишник.
ему не отвечают только по одной причине - надоел.
уже раз 20 тыкали носом в ограничения софтапдэйта (теже фичи с обнулением файлов, что и в rc ext4) - без толку.
просто тролль, прикрывающийся бздишностью. и местами java'ой (бздишнег?!!! угу)
>ему не отвечают только по одной причине - надоел.
>уже раз 20 тыкали носом в ограничения софтапдэйта (теже фичи с обнулением
>файлов, что и в rc ext4) - без толку.Механизм Soft Updates гарантирует правильную последовательность записи в файл, которуую делает программное обеспечение. Из-за сбоя в работе ФС открытые файлы физически не могут обнулится (как это нередко происходит на XFS и Ext4). В аварийных случаях содержимое открытых файлов останется в том виде, в каком оно было по времени максимум до 30 секунд до сбоя.
http://web.opennet.ru/base/sys/softupdates_idea.txt.html
вывод:
журналирования данных нет как класса. никаких writeback, ordered или journal (полное журналирование как метаданных ФС, так и пользовательских данных).
и даже с восстановлением метаданных согласно ссылке бывают большие траблы.
доп. вывод:
izen - банальный троль.
дополнение (пусть попробует прокоментировать свои "30 секунд"):
>Таким образом, softupdates зависит от двух условий.
>Во-первых, блоки должны записываться на диск в той последовательности, как ОС передает их контроллеру. Hо современные контроллеры и диски могут сами переупорядочивать запись блоков для оптимизации перемещения головок и т.п. (хотя tagged queuing позволяет ОС это отслеживать).
>Во-вторых, предполагается, что сбой не может прервать посередине операцию записи блока на диск. Умеют ли диски завершать текущую запись блока при сбое питания, я не знаю (хотя приятно было бы наэто надеяться :-)Если эти условия выполняются, то softupdates помогает ровно в одном: не будет дефектов в файловой структуре -- ее можно монтировать даже без fsck.
и вот это:
>Hо само ее состояние может соответствовать любому моменту времени в прошлом.вот поэтому народ и думает - "а нужно ли спорить с этим латентным (а может и не латентным) проприетарщиком? ему ведь все средства, любая ложь - хороши."
>Если эти условия выполняются, то softupdates помогает ровно в одном:
>не будет дефектов в файловой структуре -- ее можно монтировать даже
>без fsck.Именно к этому я тебя подводил. ;)
>и вот это:
>>Hо само ее состояние может соответствовать любому моменту времени в прошлом.
>
>вот поэтому народ и думает - "а нужно ли спорить с этим
>латентным (а может и не латентным) проприетарщиком? ему ведь все средства,
>любая ложь - хороши."Не изворачивайся как угорь в банке. :) Не констатируй того, чего я не говорил.
Никакие ФС, кроме поддерживающие технику CoW и/или полное журналирование, не могут обеспечить сохранность данных. Классические ФС при нормальной работе заботятся лишь о целостности СВОЕЙ_СТРУКТУРЫ.
Давай ты не будешь додумывать мои слова.
>Именно к этому я тебя подводил. ;)Э нет, батенька. :D
Вывод в статье один - надо поставить блок бесперебойного питания.
>Не изворачивайся как угорь в банке. :) Не констатируй того, чего я не говорил.не изворачивайся как рак в кастрюле.
твои выкрики про плачевное состояние фс в линухе сводятся к - экст3 позволяет полное журналирование, а софтапдэйт - нет. вообще.
и где твои 30 секунд? там же, http://web.opennet.ru/base/sys/softupdates_idea.txt.html
>Hо само ее состояние может соответствовать любому моменту времени в прошлом.опять врёшь? :D
>[оверквотинг удален]
>
>Э нет, батенька. :D
>Вывод в статье один - надо поставить блок бесперебойного питания.
>>Не изворачивайся как угорь в банке. :) Не констатируй того, чего я не говорил.
>
>не изворачивайся как рак в кастрюле.
>твои выкрики про плачевное состояние фс в линухе сводятся к - экст3
>позволяет полное журналирование, а софтапдэйт - нет. вообще.
>и где твои 30 секунд? там же, http://web.opennet.ru/base/sys/softupdates_idea.txt.html
>>Hо само ее состояние может соответствовать любому моменту времени в прошлом."Kirk McKusick, разработчик Berkeley FFS, решил эту проблему с помощью Soft Updates: все незавершенные обновления метаданных находятся в памяти и записываются на диск в упорядоченном виде (''упорядоченное обновления метаданных''). При значительных обновлениях метаданных более поздние обновления ''присоединяются'' к предыдущим, если они все еще находятся в памяти и еще не записаны на диск. Поэтому все операции, скажем, над каталогом, обычно выполняются в памяти перед записью обновления на диск (блоки данных сортируются в соответствии с их положением, так что они не будут записаны на диск до метаданных. При крахе операционной системы выполняется ''откат'': считается, что все операции, не записанные на диск, никогда не происходили. Файловая система находится в том состоянии, в котором она была за 30-60 секунд до сбоя. Используемый алгоритм гарантирует, что все используемые ресурсы маркированы соответствующим образом в своих областях: блоки и индексные дескрипторы. После сбоя могут остаться только ошибки выделения ресурсов, они помечаются как ''используемые'', хотя на самом деле ''свободны''. fsck(8) разбирается в ситуации и освобождает более не используемые ресурсы. После сбоя система может быть безопасно смонтирована с опцией mount -f. Для освобождения ресурсов, которые могут не использоваться, в дальнейшем потребуется запустить fsck(8). Эта идея лежит в основе background (фоновая) fsck: во время запуска системы записывается только снимок файловой системы. Все системы могут быть смонтированы в ''грязном'' состоянии, и система загружается в многопользовательский режим. Затем, фоновые fsck ставятся в очередь для всех систем, где это требуется, чтобы освободить неиспользуемые ресурсы. (Файловые системы, где не используются Soft Updates, все еще требуют запуска fsck в обычном режиме)."
>опять врёшь? :D
Угу: http://www.freebsd.org/doc/ru/books/handbook/configtuning-di...
а! уже 30-60! :D
но ладно, ведь именно это в ссылке и разбиралось. а от вас - 0 комментариев.
вывод плачевен - софтапдэйт позволяет при определенной доли везения уменьшить скорость загрузки за счет fsck после сбоя. состояние данных и метаданных не гарантированно.
и это единственное, что он может.
других возможностей нет. печально.
>http://web.opennet.ru/base/sys/softupdates_idea.txt.html
>вывод:
> журналирования данных нет как класса.Я о целостности данных не говорил. Я сказал, что файл после сбоя может быть в том виде, в котором его открыли за 30 секунд до сбоя. ВСЁ.
Журналирование данных весьма затратная операция. Если его включить на Ext3, то можно сушить вёсла — больше 6...10МБ/с скорость записи не получишь.
а я - говорил. собственно само понятие продуктивной системы об этом говорит.
т.к. плачевное состояние для продакшен системы - это не возможность гарантирования не только мета-данных (а согласно всё той же статье http://web.opennet.ru/base/sys/softupdates_idea.txt.html софтапдэт не гарантирует даже этого), но и (при желании) включения полного журналирования.нет этого в софтапдэйте. в первом случаи - ни каких гарантий (только если повезёт), во втором - просто нет.
экст же предоставляет такой выбор.
вот так то, латентный проприетарный пионер.
>а я - говорил. собственно само понятие продуктивной системы об этом говорит.
>
>т.к. плачевное состояние для продакшен системы - это не возможность гарантирования не только мета-данных (а согласно всё той же статье http://web.opennet.ru/base/sys/softupdates_idea.txt.html софтапдэт не
>гарантирует даже этого), но и (при желании) включения полного журналирования.
>
>нет этого в софтапдэйте. в первом случаи - ни каких гарантий (только
>если повезёт), во втором - просто нет.Не надо читать околонаучных рассуждений на ОпенНете. S-U гарантирует целостность ФС, независимо от того, о чём думает автор плохого пересказа.
Читать до просветления здесь: http://www.freebsd.org/doc/ru/books/handbook/configtuning-di...
раз уж первоисточник на английском не понятен.Гарантия целостности метаданных — это и есть гарантия целостности самой структуры ФС. Данные пользователя, если уцелели, считай повезло, нет — никто их специально не обнуляет, как в XFS и Ext4 при внезапном пропадании электричества. Повреждённый/недописанный вледствие внезапного останова — это всё-таки файл, а не набор нулей в XFS и Ext4.
>экст же предоставляет такой выбор.
Да, предоставляет. Но какой ценой...
>вот так то, латентный проприетарный пионер.
Не надо хамить.
>Не надо читать околонаучных рассуждений на ОпенНете. S-U гарантирует целостность ФС, независимо от того, о чём думает автор плохого пересказа.уговорил. :D
ты и до этого мало походил на ... очень упрямое и глупое животное.
>Повреждённый/недописанный вледствие внезапного останова — это всё-таки файл, а не набор нулей в XFS и Ext4.баг был потому, что в определенный момент сама прога его обнуляла, а не фс.
нда, слышишь звон, но... эх, izen, двоечник красноглазый. не нервничай так.
раз ты сам сравниваешь софтапдейт с бетой ext4, то так тому и быть, пусть будут одного уровня. :D
за 30 секунд для нагруженной бд придет абзац, что может даже repair не поможет, в чем тогда плюсы?
> В большинстве тестов ZFS-FUSE сильно отстает от EXT4, Btrfs и оригинальной реализации ZFS, что вызвано замедлением из-за использования механизма FUSE.Тесты проводил кэп?
Из тестов можно сделать один важный вывод - EXT4 рулит и педалит, и никакие Btrfs пока ему не замена.
Из этого можно сделать другой важный вывод: при наличии команды грамотных инженеров и возможности в течение десяти лет вести разработку файловой системы, не оглядываясь ни на кого, можно создать файловую систему, которая будет работать по скорости так же, как всеми давно используемые, но при этом иметь в сравнении с этими "давно используемыми" список фич, который не умещается на три экрана монитора. :)Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы спонсировала проводимые внутри неё разработки, если они просто _представляют академический интерес_?
>можно создать файловую систему, которая будет работать по скорости гораздо медленнее, чем всеми давно используемые//fix, очевидный после изучения результатов тестов по ссылке
>> можно создать файловую систему, которая будет работать по скорости гораздо медленнее,
>> чем всеми давно используемые
> //fix, очевидный после изучения результатов тестов по ссылкеО, да. Анонимус, как всегда, блещет способностью к изучению тестов. И даже не ленится дочитать отчёт до конца, в котором написаны предполагаемые причины.
>Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы
>спонсировала проводимые внутри неё разработки, если они просто _представляют академический интерес_?Berkley, MIT, NASA, CERT
>> Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы
>> спонсировала проводимые внутри неё разработки, если они просто _представляют
>> академический интерес_?
> Berkley, MIT, NASA, CERT1, 2 -- учебные заведения, 3 -- сами понимаете, там не всё можно открывать :), 4 -- научная организация.
А коммерческие компании? А?
>>> Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы
>>> спонсировала проводимые внутри неё разработки, если они просто _представляют
>>> академический интерес_?
>> Berkley, MIT, NASA, CERT
>
>1, 2 -- учебные заведения, 3 -- сами понимаете, там не всё
>можно открывать :), 4 -- научная организация.
>
>А коммерческие компании? А?Чисто академических по-моему и у Санок не было, все шло в продакшын.
Ну а так, NVidia - Cuda + OpenCL - очень даже академический софт.
У Интеля много фриварного софта, RedHat, VMware, IBM ..... в общем, без санок не умрём :)
> Чисто академических по-моему и у Санок не было, все шло в продакшын.Project Looking Glass?-)
> Ну а так, NVidia - Cuda + OpenCL - очень даже академический софт.
Был бы ещё свободным -- цены бы ему не было.
А так -- здесь согласен. BOINC вполне нормально CUDA'ой пользуется, сам проверял.
> в общем, без санок не умрём :)
Но затормозимся в прогрессе. ;)
>>> Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы
>>> спонсировала проводимые внутри неё разработки, если они просто _представляют
>>> академический интерес_?
>> Berkley, MIT, NASA, CERT
>
>1, 2 -- учебные заведения, 3 -- сами понимаете, там не всё
>можно открывать :), 4 -- научная организация.
>
>А коммерческие компании? А?intel, ibm
Ну вообще логично, что исследованиями, представляющими чисто академический интеес, занимаются научные учреждения и университеты. И, опять же, со всем уважение к SUN - её политика в целом оказалась неудачной. О причинах, конечно, разговор отдельный.
> Ну вообще логично, что исследованиями, представляющими чисто академический интеес,
> занимаются научные учреждения и университеты.И да, и нет.
В СССР конструкторские бюро не только при проектных НИИ были, но и при производствах. Каждое из них занимало свою нишу. Что-то удобнее делать рядом с академиками, что-то -- рядом со станками. _Без_ гарантии, что оно в дальнейшем пойдёт в серию.
> И, опять же, со всем уважение к SUN - её политика в целом оказалась неудачной.
> О причинах, конечно, разговор отдельный.Экспериментальный факт показывает, что таки да.
Однако, кто ещё из крупных вендоров открыл целиком проприетарную операционную систему в Open Source? Навскидку как-то никто не припоминается...
>Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы
>спонсировала проводимые внутри неё разработки, если они просто _представляют академический интерес_?Да собственно любая крупная компания. Даже майкрософт.
Занятно. Если zfs на солярке работает примерно также быстро, как btrfs в linux, а zfs на freebsd - гораздо медленнее, получается, вся проблема либо в ядре фряхи, либо в кривом портировании.А насчет скорости нативной реализации для linux я бы не стал раньше времени радоваться. Может, как с freebsd выйдет.
> Занятно. Если zfs на солярке работает примерно также быстро, как btrfs в
> linux, а zfs на freebsd - гораздо медленнее, получается, вся проблема
> либо в ядре фряхи, либо в кривом портировании.ZFS на FreeBSD работает с той же скоростью, что и ZFS в Солярисе.
Проблема вот в чём: ядро Соляриса -- полностью динамически масштабируемое. Ядро FreeBSD -- нет. Многие параметры ядра, связанные с распределением памяти -- не sysctls, а boot-time tunables. Их можно менять, только перезагрузив ядро.
По умолчанию в ядре FreeBSD параметры для ZFS выставлены крайне неоптимально. Впрочем, в ядре Соляриса тоже. Но если со вторым ZFS в Солярисе справляется "щелчком пальцами", то с FreeBSD ситуация заметно сложнее. :)
>По умолчанию в ядре FreeBSD параметры для ZFS выставлены крайне неоптимальноПрошу комментариев с примерами или ссылки на материалы, где в доступной форме можно почерпнуть...
Э-э-э-э-э...http://wiki.freebsd.org/ZFSTuningGuide -- сюда ходили?
>По умолчанию в ядре FreeBSD параметры для ZFS выставлены крайне неоптимально.Вынужден вас разочаровать: те тесты проводились на pc-bsd. Это ядро freebsd + настроенная zfs из коробки. Так что, боюсь, никакие изменения параметров уже не спасут.
у pcbsd несколько отличающаяся от нормальной fbsd ниша. я считаю что глупо делать какие-то замеры на десктоп-ориентированном дистрибутиве.
и это.. хочется узнать что означает "настроенная zfs из коробки"
> Вынужден вас разочаровать: те тесты проводились на pc-bsd. Это ядро freebsd +
> настроенная zfs из коробки.Это иллюзии. "Настроенная ZFS из коробки" будет работать на 512 мегабайтах без вопросов (сам настраивал). Кстати говоря, для OpenSolaris требования такие же. А PC-BSD отказывается её ставить меньше, чем на гектар ОЗУ. Если уж они такие "настройщики", то почему так происходит?
От неумения настраивать?-)
>Это иллюзии. "Настроенная ZFS из коробки" будет работать на 512 мегабайтах без
>вопросов (сам настраивал).а зачем, кстати? такое ограничение по памяти я могу себе в продуктиве только на виртуалке представить, но в виртуалке zfs так ли нужна? а если для дома для семьи - ну только из-за спортивного интереса.
btw сильно прикалывает тестовое железо фороникса - лаптоп с одним сата.
>> Это иллюзии. "Настроенная ZFS из коробки" будет работать на 512 мегабайтах без
>> вопросов (сам настраивал).
> а зачем, кстати?Ну как это "зачем"?
Прежде всего, для того, чтобы закрепить понимание, как правильно настраивается ядро в memory-constrained cases. Суть не в том, чтобы запихнуть 8.1/ZFS в 64 мегабайта ОЗУ. Суть в том, чтобы понять, какую гайку дёргать, если в ядре закончилась какая-нибудь память (или виртуальное адресное пространство).
>те тесты проводились на pc-bsd. Это ядро freebsd + настроенная zfs из коробки.PCBSD "из коробки" настроена на десктоп. А не на "разогнать ZFS до потолка".
Откуда дровишки про умолчальные параметры и легкость устранения проблемы? :)
> Откуда дровишки про умолчальные параметры и легкость устранения проблемы?В смысле "откуда"?
Лёгкость устранения проблем с настройками параметров ядра в Солярисе очевидна -- ZFS их настраивает автоматически. :)))
Правда, тоже не всегда: в частности, в случае Solaris Xen Domain0 всё-таки приходится пинать /etc/system, но это, если угодно, Corner Case.А что до FreeBSD -- так это вы почитайте архивы mailing list'ов времён FreeBSD v7.0-v7.2. Там много "войн" с ядром BSD на предметы, начиная от sub-optimal performance и заканчивая spontaneous crashes.
Мне кто-то из Core так и ответил: "Для ZFS параметры настраиваются методом подбора до устранения спонтанных крэшей". Дёшево и сердито. :)
Мда, вот после этого лично я точно не стану ZFS на BSD использовать...
> Мда, вот после этого лично я точно не стану ZFS на BSD использовать...Ну и напрасно. После где-то недельного траха параметры подбираются достаточно точно: у меня с мая прошлого года ни одного краха по причине ZFS у FreeBSD не было.
Зато бонусов достаточно, чтобы эту неделю потратить. Например: как вы на UFS сделаете так, чтобы можно было откатить апгрейд системы?-) Restoring from backup tapes doesn't count: это долго. А так, чтобы за время одной перезагрузки?-)
Чо? С 8-го релиза оно изредка паникует на i386 при сильной нехватке ОЗУ. А если её вполне себе хватает, свалить её очень и очень трудно. Я честно пытался и не получилось. NTFS-3G в разы проще грохнуть под нагрузкой.
> Чо? С 8-го релиза оно изредка паникует на i386 при сильной нехватке
> ОЗУ. А если её вполне себе хватает, свалить её очень и
> очень трудно. Я честно пытался и не получилось. NTFS-3G в разы
> проще грохнуть под нагрузкой.Hint: задерите сетевые буфера. ZFS'у быстро памяти хватать перестанет. ;)
8.0 amd64, до сих пор у меня падает машина если в VirtualBox начинаю очень интенсивно работать с динамическим диском (VDI) расположенном на ZFS пуле, добиться более-менее стабильной работы, что бы не падало каждые полчаса, удалось, но что бы не падало совсем - увы и ах.
>8.0 amd64, до сих пор у меня падает машина если в VirtualBox
>начинаю очень интенсивно работать с динамическим диском (VDI) расположенном на ZFS
>пуле, добиться более-менее стабильной работы, что бы не падало каждые полчаса,
>удалось, но что бы не падало совсем - увы и ах.Обновиться до 8.1 не пробовали? Говорят, помогает.
>Обновиться до 8.1 не пробовали? Говорят, помогает.В планах, но руки пока не дошли.
Единственный тест в который я поверю этоIOzone: 8GB write test with a 64Kb block size
Который показывает двукратное торможения при записи, которое только зависит от FUSE. Думается, что NTFS3G тоже самое показал бы.
Посмотрел все диаграммы тестов и они меня очень удивли. Однако вспомнил, как у меня тормозит Линукс, поскольку драйвер для ati radeon 9550 сейчас тормознутый, а может он для kde4 ни как не подходит.Так вот, не может ли быть, что когда компутер выполняет тесты на ext4 и btrfs, то пользовательтским приложениям, всяким там kde4, дрова ati radeon 9550 просто не будут работать?
Лично у меня дежавю, где то я уже это видел! А это эффект я видел на ms windows 3.1, 95, 98, me, xp... Я правильно понимаю, что высокие перфомансы для ext4, btrfs фактически создают мой компьютер однозадачным для этих замечательных файловых систем, а я пользователь, программист вроде как здесь и не при чём?
>программист вроде как здесь и не при чём?iowait bug
>> программист вроде как здесь и не при чём?
> iowait bugExplain?
>>> программист вроде как здесь и не при чём?
>> iowait bug
>Explain?.... планировщик задач и ввода/вывода как-то кооперировать надо.
А то SATA контроллер захватил шину, проц и пипец....., жди другого запроса на I/O,
тогда, .... в период переключения запроса к шине, может быть успеет вклиниться процесс.
Говорил же, на многоПРОЦЕССОРНЫХ компах и со SCSI, на шине PCI-X, через MSI или даже без, таких глюков нет.
> .... планировщик задач и ввода/вывода как-то кооперировать надо.Логично.
>>> программист вроде как здесь и не при чём?
>> iowait bug
>
>Explain?https://bugzilla.kernel.org/show_bug.cgi?id=12309
Парни, есть freebsd 8-stable с последним zfs на 4ТБ (почти заполнен кажись). Давай те пишите какие тесты делать, я буду делать и выкладывать результат, если надо. Но за последний год работы зарекомендовало себя отлично, никаких тормозов, просто лапочка.
>Парни, есть freebsd 8-stable с последним zfs на 4ТБ (почти заполнен кажись).
>Давай те пишите какие тесты делать, я буду делать и выкладывать
>результат, если надо. Но за последний год работы зарекомендовало себя отлично,
>никаких тормозов, просто лапочка.Нужно проследить поведение системы под нагрузкой, когда пул заполнен на 99%. Ext4 и Btrfs в этом случае ведут себя неадекватно.
> Нужно проследить поведение системы под нагрузкой, когда пул заполнен на 99%. Ext4
> и Btrfs в этом случае ведут себя неадекватно.ZFS тоже. И любая другая copy-on-write файловая система будет в таких условиях вести себя неадекватно by design.
Я задавал этот вопрос (деградация быстродействия файловой системы при заполненном пуле) архитектору ZFS -- ответ приведён выше. ;)
>> Нужно проследить поведение системы под нагрузкой, когда пул заполнен на 99%. Ext4
>> и Btrfs в этом случае ведут себя неадекватно.
>
>ZFS тоже. И любая другая copy-on-write файловая система будет в таких условиях
>вести себя неадекватно by design.К сожалению, ответ "тоже будет вести себя" меня не устраивает.
>Я задавал этот вопрос (деградация быстродействия файловой системы при заполненном пуле) архитектору
>ZFS -- ответ приведён выше. ;)Где?! Конкретика?
Ну кому интересно как там работает FUSE, когда уже две нативные реализации есть? Только форониксу...
> Представлены результаты сравнения производительности работающей в пространстве пользователя реализации файловой системы ZFS - ZFS-FUSE (0.6.9 и тестовый выпуск 0.7.0) с файловыми системами EXT4 и Btrfs. Сравнение проводилось в установленном по умолчанию дистрибутиве Ubuntu 10.04.1 (x86_64).И текст по ссылке:
> For our testing of ZFS-FUSE, we used both the latest stable 0.6.9 release and a 0.7.0 Git snapshot as of their latest official code in their Git repository as of 2010-08-28....
> For this ZFS-FUSE benchmarking we performed a clean installation of Ubuntu 10.04.1 LTS (x86_64) and installed the latest Linux kernel Git code for Linux 2.6.36 as of 2010-08-26.С одной стороны, Ubuntu 10.04.1 "из коробки".
С другой стороны, и ядро Linux, и подсистема ZFS-FUSE скомпилированы (на этой машине, я так полагаю) из исходников с git репозитория.
Т.е. взяли "официальный дистрибутив из коробки".
И всего-лишь добавили ядро и фс из git.
Насколько "изкоробочным" можно считать такое решение, если производительность здесь зависит только от ядра и файловой системы, а ОБА как раз взяты далеко не "из коробки"?
> Насколько "изкоробочным" можно считать такое решение, если производительность здесь
> зависит только от ядра и файловой системы, а ОБА как раз взяты далеко не "из коробки"?Эхъ.
"... Один закоммитит работающую лампочку, пока все слишном заняты срачем, чтобы это заметить..."
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/funnies...
Да, Фороникс такой Фороникс. ;)
непонимаю этот фанатизм по поводу zfs. все равно по скорости она не догонит ext4, так с чего же сыр бор затевать?
>непонимаю этот фанатизм по поводу zfs. все равно по скорости она не
>догонит ext4, так с чего же сыр бор затевать?Вот когда форониксы сделают "zfs set checksum=off poolname/testfilesystem", тогда можно будет сравнить. ;)
izen открыл для себя тюнинг фс.
если чё, то в бтр тоже checksum работает
https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_fu...
>Currently Btrfs uses crc32c for data and metadata. The disk format has room for 256bits of checksum for metadata and up to a full leaf block (roughly 4k or more) for data blocks. Over time we'll add support for more checksum alternatives.так что ещё один факт лжи izen'а зафикшен.
>izen открыл для себя тюнинг фс.
>если чё, то в бтр тоже checksum работаетЯ в курсе, к.О.
>так что ещё один факт лжи izen'а зафикшен.
Тобой? Ну-ну. По-моему, я нигде ещё не сравнивал ZFS с Btrfs кроме как в контексте чисто маркетинговых перспектив.
ну конечно! :D
ты сравнивал с ext4 (и однозначно "в контексте чисто маркетинговых перспектив").
и не важно что ext4 чуть быстрее бтр, которая в свою очередь быстрее zfs.
никакой связи и закономерностей. главное что есть повод наехать на фроникс - т.пые же.
>ну конечно! :D
>ты сравнивал с ext4 (и однозначно "в контексте чисто маркетинговых перспектив").
>и не важно что ext4 чуть быстрее бтр, которая в свою очередь
>быстрее zfs.
>никакой связи и закономерностей. главное что есть повод наехать на фроникс -
>т.пые же.У тебя что-то с логикой.
Я отвечал конкретно на эту сентенцию:
Вопрос: "непонимаю этот фанатизм по поводу zfs. все равно по скорости она не догонит ext4, так с чего же сыр бор затевать?"
Мой ответ: "Вот когда форониксы сделают "zfs set checksum=off poolname/testfilesystem", тогда можно будет сравнить. ;)"Чего тут нелогичного? ZFS и Ext4 можно будет сравнивать, когда ZFS приведут к тому состоянию, в котором находится Ext4, чтобы было что с чем сравнивать.
да нет, батенька, с логикой траблы у тебя.
большие траблы.
в ext4 тоже отруби тогда, умник
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Journal_ch...плохому танцору всегда что-то мешает.
izen, ты танцевать умеешь?
>>непонимаю этот фанатизм по поводу zfs. все равно по скорости она не
>>догонит ext4, так с чего же сыр бор затевать?
>
>Вот когда форониксы сделают "zfs set checksum=off poolname/testfilesystem", тогда можно будет сравнить.
>;)Да ладно. Оверхед от контрольных сумм там скорее всего сущие копейки. Там в другом дело. tiobench по умолчанию пишет блоками по 4К, что совпадает с размером страницы памяти, которыми оперируют btrfs и ext4, но не совпадает с размером блока по умолчанию в 128К, которым оперирует ZFS. Интереснее было бы посмотреть результаты того же теста, но с блоком 128К. Ну и плюс какие-нибудь косяки с флэшем могут вносить свою лепту
каким образом?
http://lwn.net/Articles/342892/
>ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object.а вот и основная разница
>In summary, btrfs organizes everything on disk into a btree of extents containing items and data. ZFS organizes everything on disk into a tree of block pointers, with different block sizes depending on the object size.вот такие они, соляро-бсд-java-zfs'ники.
> каким образом?
>http://lwn.net/Articles/342892/
>>ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object.А вот таким - до тех пор, пока объект меньше чем recordsize, установленный для файловой системы, он занимает места ровно столько, сколько нужно секторов для его хранения. Как только он перешагивает через recordsize, то каждый блок в этом объекте становится размером recordsize.
Поскольку фороникс все тестирует с установками по умолчанию, вот и получаются файлы размером 32M состоящие и блоков 128КБ, соответственно, при перезаписи случайным образом блокаи размером по 4КБ получается много лишней работы. То есть надо или конфигурить recordsize 4КБ, или заставлять tiobench писать блоками по 128КБ, чтобы получилось сравнение яблок с яблоками, а не с вишнями.
> вот такие они, соляро-бсд-java-zfs'ники.
Сказать-то что хотел?
не верно. по скольку уже выяснили, что zfs совсем не обязатльно иметь блок размером именно в 128к. также логично предположить, что время выделения блока любого размера из перечисленных - это О(1). более того, для бтр в 32М блоков по 4к большее количество получается, чем для zfs по 128к. опять же, любое прикладное по не выделяет блоки, оно просто передает порцию данных для io (объектом же является весь файл, а не его куски), соответственно сколько блоков выделять, в каком количестве и как это согласуется с конкретным физ.девайсом, секторами, головками и пр.
поэтому ваше предположение, что zfs не умеет этого делать - хм, смешно как минимум.
т.е. абсолютно не факт, что если вы пишете в файл порциями по N, то и блок будет по N.
еще раз прочтите (про ахилесову пяту zfs - SLAB):
>The central on-disk data structure was the slab - a chunk of disk divided up into the same size blocks, like that in the SLAB kernel memory allocator, which he also created. Instead of extents, ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object.вот все его плюсы и минусы в популярном изложении http://en.wikipedia.org/wiki/Slab_allocation
>Slab – объем памяти, за счет которого кэш может увеличиваться или уменьшаться. Он представляет собой распределение памяти в кэш, а его размер обычно кратен размеру страницы памяти. Slab должен содержать список свободных буферов, а также список буферов, которые были выделены (в случае большого размера slab’а).так что панацея отменяется.
Все, что ты написал - неверно. Не хочешь верить мне - продолжай дальше верить статье дамы, которая в последний раз в код ZFS заглядывала в 2004 году. Ну или обратить к первоисточнику - самому коду, - если хватит терпения и времени разобраться.
хочешь сказать что zfs пошла по пути регрессий? :D
ну а если нет, то и сам поймешь почему порции данных, отличные от 4к ничего не изменят.
зы:
думаю ты уже и сам понял что фигню сморозил. про ахилесову пяту, slab, я не настаиваю. может он и стал лучше (что заметно снизит потребность в озу). но лучше бтри не получится.
но речь шла не об этом, а о размерах блоков. а они никах от порций на io не зависят.
сам посуди, иначе все файлы, имеющие структуру (exe, elf, avi, jpg,..) и имеющий маленький заголовок (первая порция на запись), а это почти все файлы - имели бы и блоки 512, ну максимум 4к.
ззы:
можно сколько угодно раздувать щеки, отсылать к исходникам - это не прибавит знаний, здравого смысла и конструктива к разговору.
>хочешь сказать что zfs пошла по пути регрессий? :DКаких регрессий? Ты о чем?
>ну а если нет, то и сам поймешь почему порции данных, отличные
>от 4к ничего не изменят.Ты вместо того, чтобы тут демагогию разводить, взял бы да попробовал - сам бы все и увидел.
>зы:
>думаю ты уже и сам понял что фигню сморозил.Фигню тут ты несешь. Ты даже не попытался понять, то что я написал
> про ахилесову пяту, slab, я не настаиваю. может он и стал лучше (что заметно снизит потребность в озу)
Вот видишь, даже сам отползать начинаешь.
> но лучше бтри не получится.
Конечно, лучше бтр сделать нельзя.
>но речь шла не об этом, а о размерах блоков. а они никах от порций на io не зависят.
Ты сам то понимаешь, что ты пишешь? Еще раз перечитай, то, что я написал. И попробуй понять, прежде чем хвататься за клавиатуру
>сам посуди, иначе все файлы, имеющие структуру (exe, elf, avi, jpg,..) и
>имеющий маленький заголовок (первая порция на запись), а это почти все
>файлы - имели бы и блоки 512, ну максимум 4к.Объясняю еще раз специально для тебя - размер блока, который ZFS будет использовать для хранения файла, зависит не от структуры этого файла, а от значения свойства recordsize для файловой системы и размера самого файла. Пока размер файла меньше, чем значение recordsize, файл может поместиться в одном блоке и размер этого блока составляет минимальное количество секторов, необходимое для сохранения файла, и может меняться - если файл вырастет (но не дорастет до recordsize), размер блока тоже вырастет, если уменьшится - размер блока тоже уменьшится. Как только файл перерастает recordsize, ZFS фиксирует для него размер блока. То есть при recordsize по умолчанию, файл размером 129К будет занимать два блока по 128К, а модификация блока размером 4К внутри любого из этих двух блоков, потребует чтения блока 128К с диска (если его не найдется в кэше), модификации 4К в нем, выделения нового блока 128К и записи его.
Если у тебя файл структурирован и имеет записи фиксированного размера, как в тесте Threaded IO Tester фороникса, где размер блока по умолчанию составляет 4К, то recordsize нужно сделать равным размеру записи, чтобы получилось сравнение яблок с яблоками.
Ну или увеличивать размер блока в Threaded IO Tester до 128К.
>ззы:
>можно сколько угодно раздувать щеки, отсылать к исходникам - это не прибавит
>знаний, здравого смысла и конструктива к разговору.Вот и не раздувай. Ибо пока ни знаний, ни здравого смысла, ни конструктива ты ни на йоту не добавил.
>Каких регрессий? Ты о чем?о том, что вы предположили, что zfs не в состоянии для файла в 32М создавать блоки по 128к, если порции по 4к.
>Вот видишь, даже сам отползать начинаешь.с культурой общения у вас БА_А_Альшие траблы.
речь была не об убогости слаб. вот и все.
>Объясняю еще раз специально для тебя - размер блока, который ZFS будет использовать для хранения файла, зависит не от структуры этого файла, а от значения свойства recordsize для файловой системы и размера самого файла.и какое же значение recordsize у zfs?:D
>как в тесте Threaded IO Tester фороникса, где размер блока по умолчанию составляет 4Кв тесте нет блоков, есть буферы для вводв-вывода.
блоки - это исключительно понятия фс. и на пользовательском уровне не применяются.
зы:
на "вы" вас мама не учила общаться?
>>Каких регрессий? Ты о чем?
>
>о том, что вы предположили, что zfs не в состоянии для файла
>в 32М создавать блоки по 128к, если порции по 4к.Я ничего не предполагал. Я Вам описал, как там все работает на самом деле. Вы не поняли. До сих пор
>>Вот видишь, даже сам отползать начинаешь.
>
>с культурой общения у вас БА_А_Альшие траблы.Не большие чем, у Вас, анонимный собеседник.
>>Объясняю еще раз специально для тебя - размер блока, который ZFS будет использовать для хранения файла, зависит не от структуры этого файла, а от значения свойства recordsize для файловой системы и размера самого файла.
>
>и какое же значение recordsize у zfs?:DЧитайте внимательнее. Значение recordsize по умолчанию было названо. Фороникс все тестирует по умолчанию, так что..
>>как в тесте Threaded IO Tester фороникса, где размер блока по умолчанию составляет 4К
>
>в тесте нет блоков, есть буферы для вводв-вывода.Вы в этот тест даже не заглядывали, а рассуждаете, что там есть и чего нету. Загляните и убедитесь.
>блоки - это исключительно понятия фс. и на пользовательском уровне не применяются.Да-да, конечно. Вам самому не смешно?
http://en.wikipedia.org/wiki/ZFS#Variable_block_sizes
>ZFS uses variable-sized blocks of up to 128 kilobytes. The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks. Automatic tuning to match workload characteristics is contemplated.где в новости (и в тесте) упоминание того, что в opensolaris максимальный размер блока в zfs установлен в 4к?
>If data compression (LZJB) is enabled, variable block sizes are used. If a block can be compressed to fit into a smaller block size, the smaller size is used on the disk to use less storage and improve IO throughput (though at the cost of increased CPU use for the compression and decompression operations).ps:
>>блоки - это исключительно понятия фс. и на пользовательском уровне не применяются
>Да-да, конечно. Вам самому не смешно?нет. не смешно. не смешно, что солярку и zfs теперь "защищают" такие малокомпетентные "специалисты".
изменить на пользовательском уровне размер блока, это всё равно, что утверждать, что нотепад при сохранение может менять размер сектора на диске - бред одного порядка достоверности.
>http://en.wikipedia.org/wiki/ZFS#Variable_block_sizes
>>ZFS uses variable-sized blocks of up to 128 kilobytes. The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks. Automatic tuning to match workload characteristics is contemplated.
>
>где в новости (и в тесте) упоминание того, что в opensolaris максимальный
>размер блока в zfs установлен в 4к?Вот я и говорю, что он не установлен, если это непонятно. Поэтому в этом тесте сравниваются яблоки с апельсинами.
Вам объяснить, что значит вот эта фраза из вашей цитаты:
The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks
???
>ps:
>>>блоки - это исключительно понятия фс. и на пользовательском уровне не применяются
>>Да-да, конечно. Вам самому не смешно?
>
>нет. не смешно. не смешно, что солярку и zfs теперь "защищают" такие
>малокомпетентные "специалисты".Вам кажется. Можете продолжать видеть только то, что лежит на поверхности. Мне от этого будет только лучше.
>изменить на пользовательском уровне размер блока, это всё равно, что утверждать, что
>нотепад при сохранение может менять размер сектора на диске - бред
>одного порядка достоверности.Рекомендую вам, прежде чем упрекать меня в малокомпетентности, задуматься о том, насколько компетентны вы сами. А также прочитать еще раз мои слова, и найти в них, где было хоть что-то про изменение размера сектора на диске.
>Вот я и говорю, что он не установлен, если это непонятно. Поэтому в этом тесте сравниваются яблоки с апельсинами.а он установлен. вот сюрприз, правда? :D
называется установки по-умолчанию. и если вы хоть раз ставили осла и юзали zfs (в чем я сильно сомниваюсь) то должны знать даже его конкретное значение.
>А также прочитать еще раз мои слова, и найти в них, где было хоть что-то про изменение размера сектора на диске.про сектор вы не говорили, но не меньшую глупость сказали:
>Там в другом дело. tiobench по умолчанию пишет блоками по 4К, что совпадает с размером страницы памяти, которыми оперируют btrfs и ext4, но не совпадает с размером блока по умолчанию в 128К, которым оперирует ZFS.знатокам zfs сповящается - Variable block sizes........ Automatic tuning to match workload characteristics is contemplated. ... - что означает, что если zfs и принимает решение использовать блок в 128к, то только пользы для.
а tiobench вообще блоками не пишет. буферами он пишет. в юзерспейсе. а блоки (и/или inode'ы) - в кернел спейсе. оченно разные вещи знаете ли.
>>Вот я и говорю, что он не установлен, если это непонятно. Поэтому в этом тесте сравниваются яблоки с апельсинами.
>
>а он установлен. вот сюрприз, правда? :D
>называется установки по-умолчанию. и если вы хоть раз ставили осла и юзали
>zfs (в чем я сильно сомниваюсь) то должны знать даже его
>конкретное значение.Я уже устал повторять - по умолчанию свойство recordsize имеет значение 128К, что не есть лучший выбор, когда прикладная нагрузка пишет и читает блоками по 4К случайным образом. Чтобы сравнивать яблоки с яблоками в этом тесте, нужно для ZFS установить свойство recordsize в 4К. Поскольку фороникс тестирует все с установками по умолчанию, этого не было сделано, то есть использовалось для recordsize использовалось значение по умолчанию 128К. Я вроде на русском языке пишу. Что непонятно?
>>А также прочитать еще раз мои слова, и найти в них, где было хоть что-то про изменение размера сектора на диске.
>
>про сектор вы не говорили, но не меньшую глупость сказали:
>>Там в другом дело. tiobench по умолчанию пишет блоками по 4К, что совпадает с размером страницы памяти, которыми оперируют btrfs и ext4, но не совпадает с размером блока по умолчанию в 128К, которым оперирует ZFS.Предлагаю вам скачать уже исходные тексты программы tiotest, используемой в этом тесте, и убедиться самостоятельно (если, конечно, текст программы на C понимать умеете), кто здесь сказал глупость и какую именно.
>знатокам zfs сповящается - Variable block sizes........ Automatic tuning to match workload
>characteristics is contemplated. ... - что означает, что если zfs и
>принимает решение использовать блок в 128к, то только пользы для.Предлагаю вам посмотреть значение слова contemplated в словарике, и еще раз попробовать понять это предложение. Если не справитесь - скажите, попробую помочь.
>а tiobench вообще блоками не пишет. буферами он пишет. в юзерспейсе. а
>блоки (и/или inode'ы) - в кернел спейсе. оченно разные вещи знаете ли.Если вам больше нравиться называть куски фиксированного размера со смещениями, кратными этому размеру, буферами - называйте, я не против. Просто обычно их называют блоками.
>ZFS uses variable-sized blocks of up to 128 kilobytes. The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks. Automatic tuning to match workload characteristics is contemplated.переводится
>ZFS использует блоки переменного размера до 128 килобайтов. В настоящее время доступный кодекс позволяет администратору настраивать максимальный размер блока, используемый, поскольку определенные рабочие нагрузки не выступают хорошо с большими блоками. Автоматическая настройка, чтобы соответствовать особенностям рабочей нагрузки рассмотрена.
рпеевод глагола contemplate http://lingvo.yandex.ru/contemplate/%D1%81%20.../
>обдумывать, продумывать, размышлять128k - максимальный блок, 8к - блок по умолчанию с осле.
>Предлагаю вам посмотреть значение слова contemplated в словарике, и еще раз попробовать понять это предложение. Если не справитесь - скажите, попробую помочь.
предлагаю вам ознакомиться с адресным пространством ядра и адресным пространством пользователя, способами передачи данных из оного в другой, основами С и уже потом давать советы.
>Если вам больше нравиться называть куски фиксированного размера со смещениями, кратными этому размеру, буферами - называйте, я не против. Просто обычно их называют блоками.нравиться или нет - это не важно. блоком в zfs называется участок на диске перменной длины. в традиционных фс его аналог inode. получить доступ к нему можно только из пространства ядра (или из fuse, дабы тот установлен) и через системные вызовы ядра.
буфер - это область памяти. для пользовательского процесса (коим и является указанный тест, ибо он даже нифига не модуль ядра) в пользовательском адресном пространстве процесса.
т.е. НИКАКОЙ связи. удобно это вам или нет.
вы ПРОФАН Anon. это не оскорбление, это просто факт.
>вы ПРОФАН Anon. это не оскорбление, это просто факт.Ну что ж, вы можете продолжать заблуждаться сколько угодно. Мне от этого только лучше.
врядли ВАМ будет лучше.
вы ведь даже объяснить не в состоянии, как блоки-буферы вв из теста коррелируют с блоками файловой системы zfs.
и это еще не говоря про планировщик вв, кэшь, слаб и т.д.
и это печально.
>врядли ВАМ будет лучше.Ну это мне виднее, не так ли?
>вы ведь даже объяснить не в состоянии, как блоки-буферы вв из теста
>коррелируют с блоками файловой системы zfs.
>и это еще не говоря про планировщик вв, кэшь, слаб и т.д.
>
>и это печально.Я объяснил. Несколько раз. Просто некоторые люди в силу определенных особенностей не умеют воспринимать то, что до них пытаются донести, и возомнив себя экспертом и вооружившись автоматическим переводчиком и пачкой цитат из википедии пытаются сделать вид, что что-то понимают в устройстве и механизмах работы ZFS, не отдавая себе отчета в том, насколько этожалко и смешно выглядит.
И вот это действительно печально.
>Ну это мне виднее, не так ли?не так
>Я объяснил. Несколько раз. Просто некоторые люди в силу определенных особенностей не умеют воспринимать то, что до них пытаются донести, и возомнив себя экспертомкаким образом данные из буфера прикладной программы попадают в адресное пространство ядра и, затем, в блоки zfs?
ответьте только на этот вопрос. и сможете дальше пальцы кидать.
>>Ну это мне виднее, не так ли?
>
>не такПравда чтоли?
>>Я объяснил. Несколько раз. Просто некоторые люди в силу определенных особенностей не умеют воспринимать то, что до них пытаются донести, и возомнив себя экспертом
>
>каким образом данные из буфера прикладной программы попадают в адресное пространство ядра
>и, затем, в блоки zfs?Через промежуточный буфер в ARC. Правда чем тебе это поможет, я не знаю.
>ответьте только на этот вопрос. и сможете дальше пальцы кидать.
Теперь понятно, чем вы тут занимаетесь, минона.
Вот так и закончился разговор анонима-студента с Anon Y Mous :)) Правду говорят: и смех, и грех.)
http://ru.wikipedia.org/wiki/Btrfs
http://ru.wikipedia.org/wiki/ZFSСмотрим графу (уже) "разработчик", думаем.
К.О. все прения, кто круче - БТР или Зю - скоро будут не актуальны.
>Смотрим графу (уже) "разработчик", думаем.и чего?
это ничего не объясняет - бтр в апстриме ядра линуха разрабатывается, а zfs - внутри оракла.
>К.О. все прения, кто круче - БТР или Зю - скоро будут не актуальны.дык, уже.
>http://ru.wikipedia.org/wiki/Btrfs
>http://ru.wikipedia.org/wiki/ZFS
>
>Смотрим графу (уже) "разработчик", думаем.
>К.О. все прения, кто круче - БТР или Зю - скоро будут не актуальны.Я думаю, что Btrfs на Linux будет оставаться экспериментальной очень долго. Впрочем, так же, как и ZFS на Linux. Oracle не нужна ZFS на Linux. Альтернатива ZFS в Linux для Oracle, похоже, после приобретения активов Sun, тоже не очень интересна. Таким образом получается сегментирование продуктов: нишевые решения остаются в своих нишах и не мешают друг другу, не конкурируя за кошелёк клиентов.
Oracle, скорее, вложится в поддержку SOLARIS, чтобы удешевить стоимость сопровождения при существующей продажной цене, чем будет дописывать жизненно необходимый инструментальный набор для Btrfs. Приобретение готового продукта сильно уменьшило шансы доморощенной ФС попасть в продакшен.
>Я думаю, что Btrfs на Linux будет оставаться экспериментальной очень долгоВ убунте 11.04 запланирована как дефолтная fs
доморощенной? :D это zfs теперь будет доморощенной. онли. а бтр таки в апстриме.
факты и фантазии izen'а всё-таки разные вещи - разработка бтр увеличилась на порядок. таже убунту, миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию в конкретных версиях.
zfs же будет (а будет ли?) развиваться в закрытом режиме внутри оракла и только после выхода следующего блоба солярки будет доступна (а будет ли?) широким массам. с другой стороны zfs для флагманких продуктов оракла (субд, эрп,..) не особо нужна. собственно вообще не нужна.
у них свой ASM есть. и с zfs он не пересекается никак.
>разработка бтр увеличилась на порядок.Что-то не видно прогресса. fsck для Btrfs всё ещё не готов и, похоже, заброшен.
>таже убунту, миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию в конкретных версиях.
Наличие подгружаемого модуля ядра ещё ничего не говорит о готовности всей необходимой инфраструктуры.
>zfs же будет (а будет ли?) развиваться в закрытом режиме внутри оракла
>и только после выхода следующего блоба солярки будет доступна (а будет
>ли?) широким массам.Существующих возможностей ZFS выше крыши — задел есть лет на десять, чтобы это использовать в продакшене и тюнить узкие места.
>с другой стороны zfs для флагманких продуктов оракла (субд, эрп,..) не особо нужна. собственно вообще не нужна.
Им нужна унификация. Когда файловая система одна, а СУБД использует ZVOL, то не нужны дополнительные накладные расходы на сопровождение ещё чего-то. Я думаю, Oracle хорошо просекла эту фишку и будет отказываться от несвязанных и слабосвязанных между собой инструментов в пользу уже отлаженного апстрима — универсальной ZFS, наращивая её возможности не изнутри (её структура полностью завершена), а существующими средствами НАД ФС и блочными устройствами.
>у них свой ASM есть. и с zfs он не пересекается никак.
"ASM предполагает, что из неформатированных разделов диска формируются дисковые группы, внутри которых формируется своего рода облегченный специализированый вариант файловой системы для нужд БД." — ну, да, точно — ZVOL'ы подходят как нельзя кстати для "дисковых" групп под "облегчённые ФС для нужд БД".
"Управление «файлами» внутри дисковых групп берет на себя облегченный специализированый вариант экземпляра СУБД (экземпляр ASM)." — гибко дополняет отсутствующие возможности ZFS пула по эффективному управлению ZVOL'ами.
ещё раз - разработка бтр увеличилась на порядок. таже убунту, миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию в конкретных версиях.
всё остальное одним словом - слив.
ps:
>не, да, точно — ZVOL'ы подходят как нельзя кстати для "дисковых" групп под "облегчённые ФС для нужд БД".возможно (даже не говорю о том, что скорость оракловой субд под zfs (тюненная, без чексум) конкретно проседает по сравнению с ufs, vxfs, и пр http://ru.wikipedia.org/wiki/Veritas_File_System )
>VxFS является основной файловой системой в HP-UX. Также VxFS работает в Solaris, OpenSolaris, AIX, Linux, SINIX и UnixWare.проблема только в том, что этого нет. и что характерно, точно не появятся для платформ, отличных от солярки. а таких не мало. а оракл любит унифицировать свои решения, что логично.
так что возможно что бтр и в солярке появится.
>[оверквотинг удален]
>миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию
>в конкретных версиях.
>всё остальное одним словом - слив.
>ps:
>>не, да, точно — ZVOL'ы подходят как нельзя кстати для "дисковых" групп под "облегчённые ФС для нужд БД".
>
>возможно (даже не говорю о том, что скорость оракловой субд под zfs
>(тюненная, без чексум) конкретно проседает по сравнению с ufs, vxfs, и
>пр http://ru.wikipedia.org/wiki/Veritas_File_System )
>>VxFS является основной файловой системой в HP-UX. Также VxFS работает в Solaris, OpenSolaris, AIX, Linux, SINIX и UnixWare.Ну, вот, ты уже мешаешь в одну кучу виртуальные блочные устройства (ZVOL) и ФС с тюнингом по чексуммам. :)) Остановись. Отдышись.
>проблема только в том, что этого нет. и что характерно, точно не
>появятся для платформ, отличных от солярки.Oracle ASM не зависит от конкретной ФС, ему нужны просто блочные устройства.
>оракл любит унифицировать свои решения, что логично.
>так что возможно что бтр и в солярке появится.Зачем Btrfs в SOLARIS, если ZFS/ZVOL удовлетворяют потребностям использования ASM на 100%?
>Ну, вот, ты уже мешаешь в одну кучу виртуальные блочные устройства (ZVOL) и ФС с тюнингом по чексуммам. :)) Остановись. Отдышись.да нет. я последователен как никогда.
это ведь ты пытаешься вставить zvol в asm, который работает на (НА!) любой платформе, где нет никаких zvol.
проблемы с образованием?
>Зачем Btrfs в SOLARIS, если ZFS/ZVOL удовлетворяют потребностям использования ASM на 100%?где удовлетворяет? с каких пор в asm уже встроили ZFS/ZVOL? :D
ты уж совсем забрехался.
>http://ru.wikipedia.org/wiki/Btrfs
>http://ru.wikipedia.org/wiki/ZFS
>
>Смотрим графу (уже) "разработчик", думаем.
>К.О. все прения, кто круче - БТР или Зю - скоро будут
>не актуальны.там в основе своей разные идеи - посмотрим чья победит 8-)))
http://lwn.net/Articles/342892/
особенно нравятся аналогии с мышами (планцетными и сумчатыми 8-))