https://www.opennet.ru/openforum/vsluhforumID3/87814.html В рамках подготовки к выпуску ядра Linux 3.8, в файловой системе Btrfs ожидается (https://lkml.org/lkml/2012/12/17/431) ряд улучшений. Кроме всего прочего, внесен ряд патчей, нацеленных на увеличение производительности. Также отмечается, что на этой неделе будут опубликованы патчи с поддержкой RAID уровней 5 и 6.<br><br><br>Наиболее интересные моменты в pull-request (https://lkml.org/lkml/2012/12/17/431) от Криса Мэйсона (Chris Mason):<br><br>- По числу строк кода всех остальных опережает Стефан (Stefan), добавивший возможность замены диска в процессе эксплуатации. Данный вариант заметно отличается от нормальной процедуры замены диска, используемой при администрировании btrfs, в частности работает гораздо быстрее.<br>- Джозеф (Josef) работал над производительностью синхронной записи. В текущий pull request не был включен патч DIO_OWN_WAITING, обсуждавшийся в списке рассылки, однако включено много других изменений, снижающие задержки и нагрузку на процессор от системных вызовов fsync и записей с флагом O_DIRECT.<br>- https://www.opennet.ru/openforum/vsluhforumID3/87814.html#182 Sat, 29 Dec 2012 18:13:04 GMT &gt; Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего <br>&gt; не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck. <br><br>Проще задать вопрос: а собственно, где ныне Sun со своими мега-разработками :)<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#181 Sat, 29 Dec 2012 13:07:57 GMT &gt;&gt; Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и <br>&gt;&gt; не было на тот момент штатной команды "zpool import -F".<br>&gt; Проблема на самом деле не в том. А в том что средств <br>&gt; для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула <br>&gt; как я понимаю нет и не планируется.<br><br>zdb &#8212; штатная утилита отладки ZFS.<br><br>&gt; Такой подход невыгодно отличается <br>&gt; от традиционного в случае когда что-то пошло не так, факап получился <br>&gt; и авария вышла за те рамки которые предусматривали проектировщики ФС в <br>&gt; своем сферическом вакууме.<br><br>Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#180 Fri, 28 Dec 2012 06:37:23 GMT &gt;&gt; Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.<br>&gt; И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода <br>&gt; df?<br><br>Как посмотреть размер:<br><br>:~# ls -lhd /var<br>drwxr-xr-x 25 root root 4.0K Dec 26 02:43 /var<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#179 Fri, 28 Dec 2012 05:37:39 GMT Плюсую. Всегда приятно видеть человека, разбирающегося в работе системы глубоко.<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#178 Thu, 27 Dec 2012 19:39:17 GMT &gt; а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи...<br><br>На 100% во всех случаяю - нельзя, но как минимум если проблема, особенно на уровне железа а не частиц из космоса есть - шансы узнать о ней значительно повышаются. Процессор сложнее - стопроцентная проверка достоверности работы CPU штука сложная и дорогая. Тем не менее, соломку в виде ECC у кэшей там вполне себе подстеливают.<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#177 Thu, 27 Dec 2012 19:09:36 GMT &gt;&gt; для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула <br>&gt;&gt; как я понимаю нет и не планируется.<br>&gt; Видишь ли, сам принцип CoW не может позволить навернуться существующим данным<br><br>Зато может помочь сбой в фирмвари накопителя, логики контроллера, драйверов устройств и ФС, различные глюки оборудования (RAM, CPU, каналов передачи) и даже просто элементарные внезапно вылездшие бэды. <br><br>Да, ваша долбаная ZFS рассчитана только на аварии не крупнее проектного дизайна. А если у вас факап запроектного масштаба (т.е. не тот сферический факуум который предусмотрели разработчики) - ничего не знаем, разгребайте свое радиоактивное гэ сами, а мы не при чем, это не мы тот РБМК-1000 дизайнили и поставляли, наша хата вообще с краю, ничего не знаю: мы написали AS IS и все такое - попробуйте теперь с нас слупить чего-нибудь. А как вы там эти радиоактивные ошметки соберете - всем пофиг. Пускайте дескать парней с хэксэдитором, если там что-то ценное а нужного бэкапа вдруг нет.<br><br>&gt; и новым данным записат https://www.opennet.ru/openforum/vsluhforumID3/87814.html#176 Thu, 27 Dec 2012 18:39:58 GMT &gt; Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах <br>&gt; начинает тупить? В ZFS "по барабану", сколько снапшотов.<br><br>Да, там путем черной магии обманывают физику и логику, ну конечно же :). Особенно эпично подобные заявы смотрятся от эксперта по получению 6Мб/сек на шпиндель, который даже в такой позе и то не забывает верещать что дефрагер - лишний понт. Ну, знаешь, не у всех понятия о производительности дисковых ФС такие же как у тебя :)<br><br>&gt;&gt; своей волне, нарастив огромный объем изменений относительно снапшота.<br>&gt; И что?<br><br>И то - и фрагментация растет + оверхед на майнтенанс "лоскутного одеяла" выше. Чудес не бывает. И если б ты не был жабистом и понимал как работают компьютеры, ты бы понял почему лоскутное одеяло из кучи кусочков не сможет разогнаться до той же скорости что и большой непрерывный кусок, читаемый одним чихом.<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#175 Thu, 27 Dec 2012 18:30:49 GMT &gt; ты просто не видел как бекап делается неделю. <br><br>Если у вас бэкап делается [b]неделю[/b], у меня для вас плохие новости: you are doing it wrong!<br> https://www.opennet.ru/openforum/vsluhforumID3/87814.html#174 Thu, 27 Dec 2012 18:29:32 GMT &gt; Устройся в администрацию президента - от народа потом благодарность будет <br><br>Можно еще в госдуму. Тоже неплохой вариант.<br>