https://www.opennet.ru/openforum/vsluhforumID3/82908.html Представлен (https://db.usenix.org/publications/login/2012-02/) февральский номер электронного журнала ";login:", интерес в котором представляет статья "Btrfs: The Swiss Army Knife of Storage (https://db.usenix.org/publications/login/2012-02/openpdfs/Bacik.pdf)", написанная одним из разработчиков файловой системы Btrfs. В статье подробно и доступно рассказано о сегодняшнем состоянии развития Btrfs и наиболее интересных возможностях.<br><br>URL: https://db.usenix.org/publications/login/2012-02/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=33048<br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#82 Fri, 02 Mar 2012 21:46:01 GMT Всё, ссылки сдохли, теперь только платно.<br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#81 Tue, 14 Feb 2012 02:18:24 GMT &gt;&gt; выкинули протертый винт, вставили на его место другой.<br>&gt; Ну да, если вы можете позволить себе менять мерседес по мере заполнения <br>&gt; пепельницы - отличный вариант :) <br><br>ссд сейчас стоят не так дорого, а если нужно увеличивать производительность не теряя надежности - см. мой ответ.<br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#80 Mon, 13 Feb 2012 18:55:06 GMT &gt;&gt; &#8212; восстановление убитого (FAULTED) пула "подручными средствами", которые на тот <br>&gt;&gt; момент (2011-02-04) было доступно. А именно, восстановление пула методом ручного отката <br>&gt;&gt; к последней успешной транзакции записи на него, до того момента, когда <br>&gt;&gt; пул окончательно развалился.<br>&gt; Как бы тебе объяснить то? Скажи, а ты отдаешь себе отчет в <br>&gt; том что в общем случае транзакции вообще не обязаны например быть <br>&gt; последними?<br><br>Список последних транзакций либо хранится, либо не хранится. На ZFS такой список хранится.<br><br>&gt; А откат на полгода назад (если конечно такой снапшот был) <br>&gt; тебя я думаю сильно не обрадует. Если это вообще возможно.<br><br>Транзакции &#8212; не снапшоты.<br><br>&gt;&gt; Если внимательно прочитать статью о закате солнца вручную, то мы увидим, <br>&gt; ...что средств рекавери у ZFS с гулькин нос.<br><br>У Btrfs ещё нет стабильной fsck. О каком восстановлении линуксовой ФС сейчас может идти речь?<br>ZFS сохраняет состояние непротиворечивым в силу особенностей CoW и собственной архитектуры. Противоречивое https://www.opennet.ru/openforum/vsluhforumID3/82908.html#79 Mon, 13 Feb 2012 18:12:09 GMT &gt; выкинули протертый винт, вставили на его место другой.<br><br>Ну да, если вы можете позволить себе менять мерседес по мере заполнения пепельницы - отличный вариант :)<br><br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#78 Mon, 13 Feb 2012 18:11:09 GMT &gt; &#8212; восстановление убитого (FAULTED) пула "подручными средствами", которые на тот <br>&gt; момент (2011-02-04) было доступно. А именно, восстановление пула методом ручного отката <br>&gt; к последней успешной транзакции записи на него, до того момента, когда <br>&gt; пул окончательно развалился.<br><br>Как бы тебе объяснить то? Скажи, а ты отдаешь себе отчет в том что в общем случае транзакции вообще не обязаны например быть последними? А откат на полгода назад (если конечно такой снапшот был) тебя я думаю сильно не обрадует. Если это вообще возможно. <br><br>&gt; Если внимательно прочитать статью о закате солнца вручную, то мы увидим, <br><br>...что средств рекавери у ZFS с гулькин нос. Да, конкретно эту ситуацию аж пролечили, <br>&gt; Год спустя.<br>&gt; параметра -F. Так что описанный в статье приём восстановления стал обычной <br>&gt; рутинной задачей." <br>&gt; Занавес.<br><br>Занавес тут только по одному поводу: один клоун упорно не понимает что вон то лечение - катит только в сильно некоторой ситуации и с факапом должно как-то так очень ювелирно повезт https://www.opennet.ru/openforum/vsluhforumID3/82908.html#77 Mon, 13 Feb 2012 18:05:10 GMT &gt; Свалка миллиона файлов в одну диру - не правильное решение by design. <br><br>Нет, чувак, хорошая файловая система не должна испытывать проблем от миллиона файлов в 1 дире. Потому что случаи разные бывают. <br><br>А вот размазывание по куче дир/субдир кешей и прочая на уровне приложений - это как раз галимый костыль, спровоцированный тем что дерьмовые ФС не выполняют своих прямых обязанностей. <br><br>По той же логике если базу данных не удается сделать более чем 100 000 записей и чтоб работало быстро, проги должны сами по достижении 100 000 записей новые БД создавать :)<br><br>&gt; Если у вас настолько кривые руки/писульки, то не нужно их так халатно покрывать.<br><br>Кривые писульки - у тех у кого ФС тормозит от миллиона файлов в 1 дире. Это root cause. Остальное лишь сугубо костыли по устранению этого дефекта.<br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#76 Mon, 13 Feb 2012 18:01:50 GMT &gt; А ZFS v.28?<br><br>Судя по лисяре она радостно сдувается на паре бэдов. Нас так не устроит, извините.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#75 Mon, 13 Feb 2012 18:01:11 GMT &gt; у меня это делает cron-скрипт в 5 строчек.<br><br>Ну это вы видимо про постоянные снапшоты. А я про временные, которые существуют только некоторое время а потом прибиваются. Такие раз в 30 секунд сами лепятся и в случае факапа ФС просто откатывается на прошлый удачный - вот и все "рекавери от краха" (по идее теряется только то что было недописано в последние 30 секунд).<br><br>И кстати как вы с постоянными снапшотами решаете вопрос с местом на диске? Они же место жрут, потому что отличия от прощлого снапшота неизбежно надо хранить. Вы как-то расчищаете старье?<br> https://www.opennet.ru/openforum/vsluhforumID3/82908.html#74 Mon, 13 Feb 2012 17:57:38 GMT &gt; в таких "тестах": - xfs сдохнет &gt;99.9% - ntfs сдохнет &gt;50% - ext4 сдохнет &lt;30% <br><br>CoW механика такое должна пережить. Знаете в чем фундаментальное отличие? У всех перечисленных запись - деструктивная. Полное журналирование данных они не делают.<br><br>А вот btrfs от такого дохнуть не должно. Таков ее дизайн - недеструктивная запись в сторонку. Если это не работает ... стоп, а на кой хрен нам самих себя дурить? Нам же это и юзать потом. Поэтому идея протестировать во всех ситуациях, включая максимально десткие - отличная. А скажите, намного лучше если у вас рассыпется ТЕСТОВЫЙ набор данных, а настоящий зато потом переживет это, а?!<br>