https://www.opennet.me/openforum/vsluhforumID3/83868.html Крис Мэйсон из компании Oracle представил (https://lkml.org/lkml/2012/3/30/412) большую порцию изменений в файловой системе Btrfs для будущего ядра Linux 3.4. Среди изменений интеграция подготовленных проектом SUSE патчей с улучшением обработки ошибочных ситуаций, которые позволяют файловой системе прерывать ошибочные транзакции и перейти в режим только для чтения. Также отмечается изменение метода взаимодействия метаданных со страничным кэшем, увеличение агрессивности отбрасывания страниц для метаданных, ставших ненужными, и возможность работы с метаданными блоками крупнее страницы, вплоть до 64Кб (наиболее хорошие результаты наблюдаются с блоками в 16 или 32КБ). Код с поддержкой RAID 5 и 6 запланирован для включения в состав ядра 3.5.<br><br>URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTk<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=33498<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#97 Wed, 04 Apr 2012 11:17:05 GMT Некорректно выразился: не за счёт самих метаданных, конечно же, а за счёт дикой внутренней фрагментации, где метаданным тоже места не остаётся:<br><br>&gt; It is a well known fact that internal fragmentation of classic Bayer's<br>&gt; B-trees is restricted by the value 0.50 (see Appendix C). However it<br>&gt; takes place only if your tree contains records of the _same_ length<br>&gt; (for example, extent pointers). Once you put to your B-tree records<br>&gt; of variable length (restricted only by leaf size, like btrfs "inline<br>&gt; extents"), your tree LOSES this boundary<br><br>Внимательно почитайте и вдумайтесь, на что Шишкин ругается, перед своим следующим сочинением<br><br>Повторюсь: дефектный дизайн никаким допиливанием не исправить<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#96 Wed, 04 Apr 2012 05:25:03 GMT Ну жену-то - понятно! Да и про остальное - тож. :)<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#95 Wed, 04 Apr 2012 00:08:30 GMT &gt;&gt; И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило?<br>&gt; Как минимум безумная необходимость во всей системной памяти.<br><br>Вы предпочитаете, чтобы оперативная память была на 10-20% занята 90% времени всего аптайма, как в традиционных системах хранения? :)<br><br>ARC динамически изменяет свой размер, в зависимости от текущих потребностей запущенных и запускаемых приложений, но не может быть меньше 1 ГБ.<br><br>&gt; ARC можно уменьшать, угу, но пользоваться ей при этом трудно.<br><br>Разве sysctl-переменные трудно подобрать под задачи?<br>Вот отсюда почитайте: http://forum.ixbt.com/topic.cgi?id=11:43718-47#1338<br>и до конца обсуждения "тюнинга".<br><br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#93 Tue, 03 Apr 2012 21:31:32 GMT &gt; Я же написал про Reiser4, а это совсем иная файловая система чем Reiser 3 <br><br>ФС другая, а авторы те же самые. Где на этот раз они так же продолбутся? Что, на reiser3 томе нельзя хранить образа иных томов в reiser3 иначе fsck может "починить" фс в полные макароны? А им не кажется что добавить safeguards против таких факапов - не настолько уж и ракетная наука? Хотя конечно забавнее рассказывать о том что это ограничение ФС, а то что том при запуске fsck убился в вермишель - by design. Знаете, а мне вот ссыкотно такой by design использовать с такими known issues, даже если он и крут чисто академически...<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#92 Tue, 03 Apr 2012 21:27:53 GMT &gt; раз при определённых условиях она начинает пухнуть от метаданных<br><br>Чувак, создай у себя на ФС миллионы файлов 0-го размера. И удивись: ты записал 0 байтов полезных данных, а место куда-то схавалось. Наверное, потому что параметры файлов и их имена надо где-то хранить. <br><br>Вывод: твоя ФС полный отстой. Ее кпд оказался равен нулю. Хоть я и не знаю какая у тебя ФС, но к ней это 100% применимо. Так своему шишкину и передай.<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#91 Tue, 03 Apr 2012 21:25:27 GMT &gt; SGI больше нет, но их творение их надолго пережило и сейчас успешно <br>&gt; развивается. Это разве не показатель?<br><br>Показатель чего? Обычная такая ФС, на уровне всех остальных современных. В свое время очень всех донимала убиением файлов нулями, кстати. Окончательно додавили этот фичебаг в районе 2.6.28 примерно, после чего им даже стало можно пользоваться более-менее. <br><br>Загнать XFS в тормоза - не так уж и сложно. В некоторых случаях он сииииильно тупит при работе с метаданными. Например на куче мелочи ext4 его обставляет на раз. В общем SGIшники делали ФС для видеомонтажа. Да, с операциями такого плана, когда многогиговые файлы да еще в несколько потоков писать надо - оно справляется хорошо. А остальное - как повезет.<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#88 Tue, 03 Apr 2012 12:35:25 GMT &gt; Народ ждёт! Что ж такое Unix-way FS? <br><br>Судя по ненависти адептов unix-way к бинарному формату - юниксвейная ФС должна представлять собой один большой текстовый файл, непосредственно поверх блочного устройства.<br><br>Плюсы: не требуется драйвер, достаточно текстового редактора, следовательно, высокая портабельность.<br>Минусы: очень неудобно пользоваться, следовательно, практической пользы ноль. Но юниксвей, к счастью для его адептов, ничего не говорит про удобство и практическую пользу.<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#87 Tue, 03 Apr 2012 11:21:43 GMT &gt; Ага, и где теперь SGI?<br><br>SGI больше нет, но их творение их надолго пережило и сейчас успешно развивается. Это разве не показатель?<br> https://www.opennet.me/openforum/vsluhforumID3/83868.html#86 Tue, 03 Apr 2012 08:50:37 GMT &gt; Плагин к плагину &#8212; не сильно ли круто?<br><br>авторы FUSE смотрят на тебя несколько удивлённо и озадачено.<br>