https://opennet.me/openforum/vsluhforumID3/86698.html Мяо Се (Miao Xie), известный своей работой (http://www.opennet.ru/opennews/art.shtml?num=33132) по оптимизации Btrfs, опубликовал (http://www.spinics.net/lists/linux-btrfs/msg19182.html) в списке рассылки разработчиков файловой системы Btrfs набор патчей с реализацией системы кэширования буфера экстентов, позволяющий существенно сократить время поиска в дереве b+ и уменьшить продолжительность пребывания буфера экстентов в состоянии блокировки, благодаря повторному использованию результатов прошлого поиска. Итогом использования патчей является общее увеличение производительности операций с метаданными. Например, в тесте на создание 100 тыс файлов в 10 параллельных потоков наблюдается ускорение на 20%.<br><br>URL: http://www.spinics.net/lists/linux-btrfs/msg19182.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=34973<br> https://opennet.me/openforum/vsluhforumID3/86698.html#123 Wed, 03 Oct 2012 18:22:43 GMT &gt; они бегают анонимом по опеннету? <br><br>Не знаю. <br><br>&gt; да... похожесть для всех такая разная...<br><br>По описальнику подходят - несут ламерский буллшит с умным видом, а заодно меняют точку зрения на 180 градусов узнав о том что в ZFS из линуксного (sic!) варианта портирован trim.<br> https://opennet.me/openforum/vsluhforumID3/86698.html#122 Wed, 03 Oct 2012 18:16:10 GMT &gt; А ведь еще когда предупреждали &#8212; не надо говорить за всю сеть. <br><br>Это изен. Тупо лажаться - его фирменный стиль :)<br> https://opennet.me/openforum/vsluhforumID3/86698.html#121 Wed, 03 Oct 2012 18:13:24 GMT &gt; С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть <br>&gt; ли не в каждом посте о достоинствах Btrfs приводите это как <br>&gt; полезную фичу :) <br><br>Это полезная фича для очень нишевых применений. Которые сами себя журналят и потому клещатся с CoW. <br><br>&gt; Заметьте, я не предлагаю повсеместно вырубать проверку чексумм <br>&gt; на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) ) <br><br>Я думаю что на этом сильно много не выиграешь. Оно упирается в обсчет чексумм только на дистрофическом процессоре и очень высоких скоростях. В бенчах тоже никто CoW не отключает. Это точечная ситуационная мера для адресных применений когда логика CoW не стыкуется с логикой работы с журналируемой структурой типа БД. <br><br>&gt; Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с <br>&gt; помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck.<br><br>Может и не вычиститься. Это на классике технически невозможно при случае когда крах случился в середине записи а журналинг был тольк https://opennet.me/openforum/vsluhforumID3/86698.html#120 Wed, 03 Oct 2012 17:54:29 GMT &gt; Недописанный в транзакции файл будет оставаться в том состоянии, в котором его <br>&gt; оставили в предыдущей (завершённой) транзакции. Всё по-честноку. Есть ещё вопросы к ФС?<br><br>Это даже не столько к ФС сколько к общему свойству CoW механики. Как-то сильно по другому это реализовывать просто нелогично.<br><br> https://opennet.me/openforum/vsluhforumID3/86698.html#119 Wed, 03 Oct 2012 17:49:41 GMT &gt; Среди линуксовых ФС, пожалуй, только XFS заточена под такое [целевое] использование. <br><br>XFS - разновидность обычного экстентного аллокатора. Просто оптимизанутая на многопоточность и многодисковые конфиги за счет allocation groups. А на однодисковой конфиге - оно сравнимо с иными экстентными по свойствам, тем же ext4 например. Ну с точностью до разницы в ряде алгоритмов/метаданных. <br><br>Понимаешь, экстентом можно сразу заказать 100500 килобайтов. А не блоками. Особенно хорошо если есть такой непрерывный блок свободного места. Может прямо 1 операцией и заадресоваться, тогда как блочник будет дрюкаться с пометкой кучи блоков как занятых. На чем и протормозит. Теперь ты понимаешь почему экстенты - это суперсет блоков переменного размера? :)<br> https://opennet.me/openforum/vsluhforumID3/86698.html#118 Wed, 03 Oct 2012 17:45:09 GMT &gt; Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю, <br><br>А я бесплатно могу, так что вы неэффективный просаживатель бабла. А вот например нанесение вполне себе сложного граффити на стену - дается уже немногим.<br> https://opennet.me/openforum/vsluhforumID3/86698.html#117 Wed, 03 Oct 2012 16:29:45 GMT &gt;&gt;&gt;&gt;&gt;&gt; На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование <br>&gt;&gt;&gt;&gt;&gt;&gt; больших блоков ФС скорее благо, чем из ряда вон выходящее явление.<br>&gt;&gt;&gt;&gt;&gt; Напоминаю, TRIM это для SSD. =) <br>&gt;&gt;&gt;&gt; SSD не используется для видеомонтажа? Странно. Не знал.<br>&gt;&gt;&gt; ZFS годится только для видеомонтажа, буду знать.<br>&gt;&gt; И под файлопомойку тоже &#8212; отметьте там у себя.<br>&gt; Для помойки что она даёт эксклюзивного?<br><br>Надёжность и самоверифицируемость хранимых данных. Если какой-то носитель в избыточном массиве начинает "сыпаться", то ZFS на лету исправляет ошибки. Когда такой носитель совсем помирает, то ZFS сигнализирует о потере бойца, но не данных.<br><br>&gt; Дедупликацию и RAID5.<br><br>Не только, а всё что угодно, согласно свойствам этой замечательной ФС.<br><br>&gt; С дедупликацией те же вилы, что и с отсутствием TRIM. Если используем <br>&gt; нормальный размер блока, получаем терабайт сожранной RAM<br><br>Странно. Мне несколько гигабайт ОЗУ хватает для трёх пулов.<br><br>&gt; и тормоза, если используем <br>&gt; дикий полумег https://opennet.me/openforum/vsluhforumID3/86698.html#116 Wed, 03 Oct 2012 10:20:09 GMT &gt; привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck &#8212; этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлись<br><br>А ведь еще когда предупреждали &#8212; не надо говорить за всю сеть.<br> https://opennet.me/openforum/vsluhforumID3/86698.html#115 Wed, 03 Oct 2012 05:41:48 GMT &gt;&gt;&gt;&gt;&gt; На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование <br>&gt;&gt;&gt;&gt;&gt; больших блоков ФС скорее благо, чем из ряда вон выходящее явление.<br>&gt;&gt;&gt;&gt; Напоминаю, TRIM это для SSD. =) <br>&gt;&gt;&gt; SSD не используется для видеомонтажа? Странно. Не знал.<br>&gt;&gt; ZFS годится только для видеомонтажа, буду знать.<br>&gt; И под файлопомойку тоже &#8212; отметьте там у себя.<br><br>Для помойки что она даёт эксклюзивного? Дедупликацию и RAID5.<br>С дедупликацией те же вилы, что и с отсутствием TRIM. Если используем нормальный размер блока, получаем терабайт сожранной RAM и тормоза, если используем дикий полумегабайтный блок(на файлопомойке! =), то не получаем никакой экономии от дедупликации.<br>Рейд-Z встроенный это конечно удобно, но учитывая, что жрёт ресурсов на объёмах в десятки терабайт ZFS в разы больше, чем MD+((LVM+ext4)&#124;btrfs), а производительность и надёжность настолько же ниже, то возникает резонный влпрос: зачем?<br>Короче тот же вывод, что и с видеомонтажом: использовать конечно можно, но одно