https://opennet.me/openforum/vsluhforumID3/83275.html Для файловой системы Btrfs были представлены (http://article.gmane.org/gmane.comp.file-systems.btrfs/15744) патчи с поддержкой алгоритма сжатия LZ4 (http://code.google.com/p/lz4/), показавшие довольно приятные результаты. LZ4 - скоростной алгоритм сжатия, как правило обгоняющий Snappy (http://www.opennet.ru/opennews/art.shtml?num=30003) по степени сжатия и способный достигать скорости сжатия в 300Мб/сек на одном ядре процессора и скорости распаковки в 1Гб/сек, достигая на многоядерной системе потолка производительности RAM. <br><br><br>Также отмечается (http://www.phoronix.com/scan.php?page=news_item&px=MTA2MDI) о создании отдельной экспериментальной ветки в Git-репозитрии (https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git;a=summary) Btrfs для тестирования реализации утилиты btrfsck, ориентированной на восстановление целостности повреждённой ФС (добавлена опция "--repair"). Ветка получила название "dangerdonteveruse (https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs...<br><br>URL: http://www.pho https://opennet.me/openforum/vsluhforumID3/83275.html#123 Thu, 03 Aug 2017 17:08:36 GMT Btrfs всё - https://www.opennet.ru/opennews/art.shtml?num=46955<br>///---<br>В категорию устаревших (deprecated) переведена поддержка Btrfs и FedFS (Federated File System). Файловая система Btrfs ранее позиционировались в дистрибутиве RHEL 7 как экспериментальная возможность (Technology Preview), не рекомендованная к применению в промышленных решениях. Компания Red Hat приняла решение не выводить Btrfs в разряд полностью поддерживаемых в RHEL технологий и поддержка данной ФС будет прекращена в будущем значительном выпуске RHEL 8. Что касается RHEL 7.4, то в Btrfs продолжен перенос некоторых изменений из upstream. В дальнейшем, пользователи следующих выпусков ветки RHEL 7 смогут продолжить использовать Btrfs, но изменения больше переноситься не будут.<br>---///<br><br> https://opennet.me/openforum/vsluhforumID3/83275.html#122 Mon, 05 Mar 2012 18:52:10 GMT &gt;&gt; Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами.<br>&gt; Лучше так чем хексэдитором, самолично разгребая еще и фрагментацию, декомпрессию, уровни <br>&gt; райда и что там еще... при том чем больше - тем <br>&gt; геморройнее ;)<br><br>scrub выполняет проверку только занятого пространства. fsck выполняет проверку всего пространства, выделенного под файловую систему. Сколько времени займёт работа fsck на ОТМОНТИРОВАННОМ разделе и scrub на ИМПОРТИРОВАННОМ (считается в работе) пуле (если во время работы scrub проверяет в первую очередь те файлы, которые запрашиваются в текущий момент и оперативно реконструирует повреждения)? Думаю, что времени займёт больше та задача, у которой фронт работ больше, а именно &#8212; fsck, не обращаясь к журналу, естественно.<br><br>Ещё какие аргументы будут?<br><br>&gt;&gt; scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить <br>&gt;&gt; не удастся, а пул станет отремонтированным.<br>&gt; Угу, на лисяре отличный пример как он станет. Конкретно эт https://opennet.me/openforum/vsluhforumID3/83275.html#121 Mon, 05 Mar 2012 18:02:24 GMT &gt; Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами. <br><br>Лучше так чем хексэдитором, самолично разгребая еще и фрагментацию, декомпрессию, уровни райда и что там еще... при том чем больше - тем геморройнее ;)<br> <br>&gt; scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить <br>&gt; не удастся, а пул станет отремонтированным. <br><br>Угу, на лисяре отличный пример как он станет. Конкретно эту ситуацию конечно пролечили, а что насчет остальных? Там настолько же плохо как и было или оно теперь натурально чинить хоть что-то умеет и там теперь не только маркетинговый булшит о ненужности fsck?<br> https://opennet.me/openforum/vsluhforumID3/83275.html#120 Mon, 05 Mar 2012 17:55:17 GMT &gt; смеются, а потом над вами смеются снова..." <br><br>Вам бы этого хотелось, да? Ну чтож, мечтайте, это не вредно :)<br><br> https://opennet.me/openforum/vsluhforumID3/83275.html#119 Mon, 05 Mar 2012 17:48:49 GMT &gt;&gt; Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни <br>&gt;&gt; на каком RAID кроме mirror ничего тебе не пролечит, <br>&gt; Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально <br>&gt; напоминает файловую систему, чем и хорош. Можно данные потом достать с <br>&gt; порушенного диска как белый человек, а не хексэдитором выколупывать...<br><br>Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами.<br>scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить не удастся, а пул станет отремонтированным. Так кто там будет лазить с hex-редактором по диску, определяя, какой файл в /lost+found откуда взялся, а? :))<br><br><br> https://opennet.me/openforum/vsluhforumID3/83275.html#118 Mon, 05 Mar 2012 13:45:05 GMT &gt; Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни <br>&gt; на каком RAID кроме mirror ничего тебе не пролечит,<br><br>Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально напоминает файловую систему, чем и хорош. Можно данные потом достать с порушенного диска как белый человек, а не хексэдитором выколупывать...<br> https://opennet.me/openforum/vsluhforumID3/83275.html#117 Mon, 05 Mar 2012 13:36:02 GMT &gt; А как насчет LZMA ? <br><br>Хоть его и портировали на чистый си в конце концов и даже в виде годном для пихания в ядро...<br>1) По скорости сжатия он еще хуже zlib, потому что делался с оглядкой на максимальное сжатие. <br>2) При мелком размере блока разогнаться с крутым сжатием особо негде и не на чем. А жать большой блок - долго и RAM много надо...<br>3) По скорости распаковки он как и все LZ-based довольно ничего, но... но довольно хардкорная несимметрия скоростей сжатия и распаковки ограничивает его применение в штуках типа squashfs или сжатия ядра, где распаковка - есть, а упаковки - нет. Просто потому что упаковка может быть длительной и потребовать много ресурсов, что слегонца неприемлимо для сжатия работающего на лету.<br><br>Технически кстати LZMA всего лишь развитие все тех же идей: 2-ступенчатый алгоритм, LZ-подобное сжатие которому дозволено юзать более крупный словарь чем zlib с его куцыми 32кб + марковские цепочки как вторая стадия. Жмет хорошо но медленно. Распаковывается более-менее резво (как и любой иной https://opennet.me/openforum/vsluhforumID3/83275.html#116 Mon, 05 Mar 2012 13:17:33 GMT &gt;&gt; scrub &#8212; это и есть fsck с другим названием.<br>&gt; Угу. И менее дотошный/способный к починке раздестроенного тома.<br><br>Ты вообще различаешь DEGRADED и FAULTED состояния системы хранения?<br><br>scrub в обычном применении лечит DEGRADED.<br>В необычном применении &#8212; после "zpool import -F faultedpoolname" scrub может лечить FAULTED-пул, импортированный "как есть", в режиме DEGRADED, если это возможно.<br>Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни на каком RAID кроме mirror ничего тебе не пролечит, а откажется выполняться.<br><br>&gt; Иначе сообщений типа того что на лисяре просто не возникало бы как класса.<br><br>В то время для импорта FAULTED пула не было опции "-F" для автоматической пробы и отмотки состояния пула от FAULTED до DEGRADED. Сейчас эта опция ЕСТЬ. ЕСТЬ! И ты заткнёшься, наконец, а?<br> https://opennet.me/openforum/vsluhforumID3/83275.html#115 Mon, 05 Mar 2012 12:39:08 GMT &gt; Если у разработчиков руки из задницы, то да.<br><br>Такие масштабные выводы на песке, конечно... :)<br><br>