https://opennet.ru/openforum/vsluhforumID3/95896.html Эдуард Шишкин объявил (http://www.spinics.net/lists/reiserfs-devel/msg03884.html) о доступности патчей (http://sourceforge.net/projects/reiser4/files/reiser4-for-linux-3.x/) с реализацией файловой системы Reiser4 (https://reiser4.wiki.kernel.org/index.php/) для ядра Linux 3.14. Новый выпуск примечателен добавлением поддержки (http://marc.info/?l=reiserfs-devel&m=139449965000686&w=2) различных транзакционных моделей, позволяющих сочетать в одной реализации ФС разных режимов обеспечения целостности, оптимальных для разных типов носителей.<br><br><br>Обычно файловые системы поддерживают только одну, жестковкодированную транзакционную модель. Это либо только журналирование (как в ReiserFS (v3), ext4, XFS), либо только Write-Anywhere (более известная как Copy-on-Write), как в ZFS, Btrfs). Однако, журналируемые файловые системы не лучший выбор для<br>SSD-дисков из-за двойных записей (все модифицированные блоки<br>записываются сначала в журнал, потом на штатное место на диске).<br>И, наоборот, CoW-файловые системы плохо работают https://opennet.ru/openforum/vsluhforumID3/95896.html#181 Sat, 11 May 2019 15:46:36 GMT Ну и правильно, основной костяк R4 (алгоритмы, структуры, размеры тех или иных параметров и т.п.) сделали еще в Namesys, с участием Ганза и пары математических универов (в отличии от Btrfs, в котором нифига не продумано).<br> https://opennet.ru/openforum/vsluhforumID3/95896.html#180 Wed, 28 May 2014 12:37:24 GMT &gt; Вот, оказывается ваш посыл в новость - невалидный.<br><br>Слыхали. Тру - по ссылкам не ходят, в носу козявки вкуснее выковыривать...<br><br>&gt;&gt; многие с патчами).<br>&gt; Если посмотреть на их патчи большинство из них просто техническая работа напильником, <br>&gt; ФС саму по себе не улучшает.<br><br>Может ее просто не надо улучшать? Впрочем, в напильниках я не разбираюсь... Лишь отметил наличие людей, разбирающихся в коде и присылающих патчи.<br> https://opennet.ru/openforum/vsluhforumID3/95896.html#179 Sat, 24 May 2014 11:28:55 GMT &gt; Не кажется что тут получается подозрительно много операций со стороны ФС, которые к тому же превращают файловую систему и файлы в мелкую такую вермишельку<br><br>Хуже чем в reiserfs(v3) быть не должно: там вермишель (это когда нет экстентов, т.е. один блок - один указатель на него) заложена в дизайн. А reiserfs очень даже шустра.<br><br>&gt; и дико загаживают ФС метаданными?<br><br>Btrfs - да, загаживает в виду отсутствия адэкватной алгоритмической базы. Граммотно спроектированные файловые системы такое себе не позволяют.<br> https://opennet.ru/openforum/vsluhforumID3/95896.html#178 Fri, 23 May 2014 09:36:37 GMT &gt;[оверквотинг удален]<br>&gt; его in-place воткнуть, но CoW об этом ничего не знал. И <br>&gt; вообще это не его собачье дело. Он видит - "файл поменяли". <br>&gt; Значит, выносок! С новой версией. Вон туда, вбок.<br>&gt; 3) Чистим журнал. Для CoW - "журнал опять поменяли, делаем выносок/пометку в <br>&gt; метаданных".<br>&gt; Не кажется что тут получается подозрительно много операций со стороны ФС, которые <br>&gt; к тому же превращают файловую систему и файлы в мелкую такую <br>&gt; вермишельку и дико загаживают ФС метаданными? На самом деле от ФС <br>&gt; хотели всего 2 блочные операции in-place, в журнале и в базе. <br>&gt; А вышло вона как.<br><br>Ну вообще-то на самом деле от ФС хотели не только две блочные операции :-) Но ещё видимо и сохранения старых версий файлов. Что и повлекло. ФС здесь на самом деле никак не "помогает" БД, а делает свою часть работы.<br>Предположим, в пункте 1 COW догадывается, что фрагмент нужен на короткое время. Есть альтернатива? (на самом деле надо чтобы версии журнала не сохранялись).<br>В случае, когда старые версии данных в фай https://opennet.ru/openforum/vsluhforumID3/95896.html#177 Fri, 23 May 2014 09:25:14 GMT &gt; а у нас защита от глупости заложена в логику работы файловой системы<br><br>Давно уже доказано, что защиту от глупости в логику работы файловой системы заложить принципиально невозможно. И нее что, искусственный интеллект?<br> https://opennet.ru/openforum/vsluhforumID3/95896.html#176 Fri, 23 May 2014 03:07:27 GMT &gt; Правильно, нефиг. Нехай в вермишель превращается.<br><br>Мега-админ своего уютненького локалхоста пыжится рассуждать как матёрый айтишник, хотя ни разу в глаза не видал серьёзные системы хранения данных.<br> https://opennet.ru/openforum/vsluhforumID3/95896.html#175 Thu, 22 May 2014 16:20:22 GMT &gt; А кто-то изучал насколько вообще неоптимально получается в типовых случаях? Или так, <br>&gt; пальцем в небо? Мне почему-то кажется что второе.<br><br>тебе неправильно кажется. это, впрочем, уровень домашнего задания первокурсника, а не научной работы.<br><br>&gt; Насколько я помню, "эпидемия" с редизайном функций хеш-таблиц в дуракоустойчивом виде случилась <br>&gt; лишь недавно, год-два назад.<br><br>ага-ага. например, статья Боба Дженкинса в Dr.Dobb's за 1997-й год. это так, на вскидку из самого известного.<br><br>я же говорю: у тебя в этой теме огромный пробел.<br><br>&gt; Ну твое мнение по поводу качества софта тоже не больно ценное, если <br>&gt; ты прощаешь рейзеру настолько махровые баги и в дизайне структур<br><br>ты уверен, что это баг? поясни, пожалуйста, где и как надо было сделать лучше. нет, не в стиле &#171;да в структурах, надо было не так&#187;, а с описанием структуры, хранения, точечным указанием, что неверно и описанием замены. можно использовать код reiser3 как reference.<br><br>извини, но у меня есть уверенность, что ты не разбирался в https://opennet.ru/openforum/vsluhforumID3/95896.html#174 Thu, 22 May 2014 15:53:48 GMT &gt;&gt; ZVOL &#8212; это не файл.<br>&gt; Вот я и не понимаю - к чему было твое лопотание?<br><br>К тому, что ZFS не может хранить саму себя не то что бы в файле, а в двоичном образе в активном пуле &#8212; не даёт создать пул на основе "чужих" ZVOL.<br><br>&gt; Как оно коррелирует с случаем когда в ФС хранился файл с виртуалкой, <br>&gt; а глупый fsck при налете на деревья из этого файла - <br>&gt; "починил" основной том по этим данным, используя дереаья от диска виртуалки.<br><br>Коррелирует в том смысле, что fsck у вас действительно глупый, раз допускает такие ситуации, а у нас защита от глупости заложена в логику работы файловой системы (иначе по-другому это и не назовёшь).<br><br>&gt; Поскольку это были разные файловые системы - основной том, разумеется, будет полностью уничтожен.<br><br>Ах, "разумеется"? Ну-ну.<br> https://opennet.ru/openforum/vsluhforumID3/95896.html#173 Thu, 22 May 2014 13:48:15 GMT &gt;&gt; Про то, что сервер перезагружают, я узнал очень не сразу <br>&gt; А сейчас я вам расскажу, что во многих дистрибутивах при старте запускается <br>&gt; fsck и проверяет фс перед монтированием в режиме rw. Проверка производится, <br>&gt; если с момента предыдущей проверки прошло достаточное кол-во времени или достаточное <br>&gt; кол-во операций монтирования фс.<br><br>Ну вообще-то это есть, мне кажется, один из багов старых методов старта систем. Первоначальная задача этого fsck довольно успешно переложена на саму ФС, зачем в общем-то и нужен журнал и прочее. То есть ошибки появляться не должны. А если появляются, то... Здесь уже видимо автоматическим fsck чаще может быть и не обойтись...<br><br>