https://opennet.ru/openforum/vsluhforumID3/83092.html Разработчики проекта Fedora Linux вновь отложили (https://fedoraproject.org/w/index.php?title=Features/F17BtrfsDefaultFs&diff=270634&oldid=prev) переход на использование по умолчанию файловой системы Btrfs. Изначально переход на Btrfs по умолчанию изначально планировался в Fedora 16, но был отменён (http://www.opennet.ru/opennews/art.shtml?num=31430) из-за неготовности утилиты btrfsck для проверки целостности и восстановления файловой системы после сбоя. Подобная утилита в конечном счёте была подготовлена, но пока присутствует в Git-репозитории (https://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_source_repositories.html) btrfs-progs и ещё недостаточно протестирована. Кроме того, остаются неустранёнными недоработки (https://fedorahosted.org/fesco/ticket/704) в поддержке Btrfs в инсталляторе Anaconda. В частности, отсутствует возможность интерактивного изменения Btrfs-разделов во встроенном в инсталлятор редакторе разделов. Таким образом ожидать активации по умолчанию Btrfs приходится только в осеннем релизе Fe https://opennet.ru/openforum/vsluhforumID3/83092.html#110 Sat, 25 Feb 2012 06:17:26 GMT Попробуйте сначал, а не пробуйте представить текст "переведя" его по своим критериям.<br> https://opennet.ru/openforum/vsluhforumID3/83092.html#109 Wed, 22 Feb 2012 04:30:02 GMT &gt; Сложновато назвать фиксированное на определённый момент состояние ФС полноценным бэкапом.<br><br>Снапшоты живой файловой системы, вообще-то, не являются бэкапами, так как в это время часть файлов открыты на запись.<br><br>Логическое состояние всей операционной системы должно рассматриваться в сумме как состояние файловой системы и как работающих приложений, которые используют в это время файлы для записи. Только сохранение всего состояния (и снапшот ФС, и снапшот всего ОЗУ) при допустимых условиях (например, приостановка всех таймеров на время заморозки) может являться полноценным бэкапом живой системы. Обычно же бэкап производится с пассивной ФС, смонтированной "только для чтения", или при закрытых приложениях, активно использующих запись в файлы (открытые файлы закрыты). Только так можно обеспечить целостность и непротиворечивость по крайней мере системы хранения, жертвуя в принципе ненужным логическим состоянием процессов в ОЗУ.<br> <br>&gt; Как временная мера для проведения обновления системы (чтобы откатиться, если чт https://opennet.ru/openforum/vsluhforumID3/83092.html#108 Tue, 21 Feb 2012 05:19:09 GMT &gt; Ахаха, в догонку.<br>&gt; Новые волшебные патчи ускоряют BTRFS еще на 15%.<br>&gt; http://www.phoronix.com/scan.php?page=news_item&px=MTA1ODY <br>&gt; На самом деле какой то ускоритель интернета выходит а не основная замена <br>&gt; морально устаревающей EXT.<br><br>Прочитал как "Новые волшебные палочки..."<br>Вот что спасёт киллер-FS!!!<br> https://opennet.ru/openforum/vsluhforumID3/83092.html#107 Tue, 21 Feb 2012 05:15:47 GMT &gt;&gt; Нет.<br>&gt;&gt; Шишкин &#8212; художник.<br>&gt; Нет. Шишкин - критик.<br><br>Нет. Шишкин - Шишкин!<br> https://opennet.ru/openforum/vsluhforumID3/83092.html#106 Mon, 20 Feb 2012 14:55:50 GMT &gt;&gt;&gt; Угу, расскажи мне плиз что мне делать на EXT если я файл <br>&gt;&gt;&gt; сдуру переписал бэкапом и проел изменения с момента этого бэкапа?<br>&gt;&gt; Вправить себе мозги, и организовать нормальный бэкап.<br>&gt; Потеря файла по цене может быть выше или хотя бы сопоставима с <br>&gt; организацией его бэкапа &#8212; при этом условии надо делать бэкап.<br>&gt; Стоимость системы бэкапа может быть сильно выше поддержки временных снапшотов на живой <br>&gt; ФС и возможности отката файловой системы к желаемому состоянию. ФС может <br>&gt; размещаться на отказостойчивом массиве. При этих условиях вполне применима техника<br>&gt; снимков файловой системы вместо системы бэкапа.<br><br>Сложновато назвать фиксированное на определённый момент состояние ФС полноценным бэкапом. Как временная мера для проведения обновления системы (чтобы откатиться, если что-то не получится) - отличное применение: можно быстро откатиться.<br>Но полноправный бэкап делается на отчуждаемый носитель. В случае со снапшотом это будет передача снапшота на другой сервер в сети (не знаю, делается ли https://opennet.ru/openforum/vsluhforumID3/83092.html#105 Mon, 20 Feb 2012 14:34:22 GMT &gt; вполне применима техника снимков файловой системы вместо системы бэкапа.<br><br>Шли бы вы дальше локалхост администрировать.<br> https://opennet.ru/openforum/vsluhforumID3/83092.html#104 Mon, 20 Feb 2012 13:00:45 GMT перевод с маркетологического: фигу вам, а не fsck. зато фичу &#171;мы помечаем плохие кластеры и переносим с них данные&#187; можно подать как новое крутое достижение.<br> https://opennet.ru/openforum/vsluhforumID3/83092.html#103 Mon, 20 Feb 2012 11:25:06 GMT &gt;&gt; Угу, расскажи мне плиз что мне делать на EXT если я файл <br>&gt;&gt; сдуру переписал бэкапом и проел изменения с момента этого бэкапа?<br>&gt; Вправить себе мозги, и организовать нормальный бэкап.<br><br>Потеря файла по цене может быть выше или хотя бы сопоставима с организацией его бэкапа &#8212; при этом условии надо делать бэкап.<br><br>Стоимость системы бэкапа может быть сильно выше поддержки временных снапшотов на живой ФС и возможности отката файловой системы к желаемому состоянию. ФС может размещаться на отказостойчивом массиве. При этих условиях вполне применима техника снимков файловой системы вместо системы бэкапа.<br> https://opennet.ru/openforum/vsluhforumID3/83092.html#102 Mon, 20 Feb 2012 10:52:15 GMT &gt;&gt; Что, последствия от использования btrfsck дают о себе знать?<br>&gt; В ZFS fsck до сих пор сделать не могут, так что чья бы корова мычала :)<br><br>RTFM!<br>http://docs.oracle.com/cd/E19253-01/820-0836/gbbwa/index.html<br><br>"Проверка данных<br>Помимо восстановления данных служебная программа fsck осуществляет проверку на отсутствие проблем в данных, хранящихся на диске. Традиционно эта задача выполнялась путем размонтирования файловой системы и выполнения служебной программы fsck, возможно, с переводом системы в однопользовательский режим. Этот случай приводит к простою, продолжительность которого пропорциональна размеру проверяемой файловой системы. Вместо явного вызова служебной программы для выполнения необходимой проверки ZFS предоставляет механизм программной проверки всего объема данных. Эта функциональность, называемая очисткой (scrubbing), обычно применяется для памяти и файловых систем в целях обнаружения и предотвращения ошибок до того, как они приведут к сбою оборудования или программного обеспечения.<br><br>Управл