https://opennet.ru/openforum/vsluhforumID3/129098.html Александр Ларсон (Alexander Larsson), создатель Flatpak, работающий в компании Red Hat, представил предварительный вариант патчей с реализацией файловой системы Composefs для ядра Linux. Предложенная файловая система напоминает Squashfs и также подходит для монтирования образов в режиме только для чтения. Отличия сводятся к обеспечению в Composefs эффективного совместного хранения содержимого нескольких примонтированных дисковых образов и поддержке проверки подлинности читаемых данных. В качестве областей применения, в которых может оказаться востребована ФС Composefs, называется монтирование образов контейнеров и применение для Git-подобного репозитория OSTree...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58212<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#169 Tue, 06 Dec 2022 10:25:08 GMT &gt;&gt; Только вот сделана эта фс специально под fs-verify который будет хэши считать <br>&gt;&gt; постоянно.<br>&gt; Для чего хэши считать постоянно? Ещё раз: эта файловая система монтируется в <br>&gt; режиме "только для чтения".<br><br>Для валидации данных очевидно. Все данные на оригинальной фс остаются в режиме записи.<br><br>Посмотрев на авторов становится очевидно что composefs скрестят с ostree хранилищем и получат подписанные образы на базе произвольного стора, которые можно будет встроить в secureboot цепочку(тут валидация и становится актуальной). Всё это актуально для silverblue подобных дистров.<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#168 Mon, 05 Dec 2022 10:37:26 GMT &gt; Когда у файла 80% блоков совпадает, эти блоки БУДУТ заменены на референсы. <br>&gt; Это прекрасно работает с образами виртуалок из 1 шаблона, разными версиями <br>&gt; данных с общим предком и проч. А если в имени файла <br>&gt; закодирован весь хэш всего файла - глобальный sha файлов все же <br>&gt; разный, вон то уже не сработает. Будет 2 полностью разных файла. <br><br>Читай внимательно: хэш считается у блоков. Если меняется какая-то часть -- только это блок будет посчитан заново и ссылка будет заменена новым хэшем. Все остальные блоки (и хэши) останутся прежними). Если 80% блоков общие -- откуда жор памяти? А таблица страниц памяти -- жор в памяти не устраивает?<br><br> https://opennet.ru/openforum/vsluhforumID3/129098.html#167 Mon, 05 Dec 2022 10:34:23 GMT &gt; Только вот сделана эта фс специально под fs-verify который будет хэши считать <br>&gt; постоянно.<br><br>Для чего хэши считать постоянно? Ещё раз: эта файловая система монтируется в режиме "только для чтения".<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#166 Mon, 05 Dec 2022 08:46:32 GMT внутривенно<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#165 Mon, 05 Dec 2022 07:51:03 GMT не пойдёт, в ZFS и 512 байт можно.<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#164 Sun, 04 Dec 2022 05:34:26 GMT &gt; MS не так давно признавал такой факап, требующий определенных условий<br><br>Ссылка на источник тоже имеется?<br>&gt; откровенная сыпучка разве что у вон тех энтерпрайзников бездумно кладущие кеши на SSD<br><br>WD никогда не выпускала SSD под маркой Purple. Пометь уже там в своей методичке..<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#163 Sun, 04 Dec 2022 01:35:54 GMT Теоретически, оттуда следует что это обычный диск с 4К секторами. Не очень понятно как и почему он партишн потерял, или что под "raw диском" имелось в виду?<br><br>&gt; то это говорит, что вы не очень-то и разбираетесь - все на предположениях..<br><br>WD понаплодили линеек, да. А то было похоже на "крупноблочный облом". Но видимо не оно. В природе много странной ерунды, однако я уверен что слет партишна не является нормальным состоянием дел и EXT4 в этом не замечен. Как и вообще в внезапных харакири без причин. Если б вы это про NTFS сказали - там MS удалось вычислить в определенном случае, после начала массовых осыпонов. Но вон то является чем-то довольно нетипичным. И больше всего похоже на кривую работу железа.<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#162 Sun, 04 Dec 2022 01:31:04 GMT &gt; Диск отработавший 1022 часа через "безопасное отключение" стал raw вместо ext4 и <br>&gt; теперь программами testdisk и dmde не находится даже суперблок, не говоря <br>&gt; уж о резервном загрузчике..<br><br>Так на диске то что в результате? Таблица разделов есть? Какие-то правдоподобные данные остались? Если б вы NTFS сказали - окей, для него MS не так давно признавал такой факап, требующий определенных условий, их дожали после того как у юзеров сыпучка стала массово случаться. Но в линухе вот именно такой грабли не припоминается. Там откровенная сыпучка разве что у вон тех энтерпрайзников бездумно кладущие кеши на SSD, а когда тот протирается и продалбывает несколько крупных блоков - ну, ок, это превышает допущения большинства ФС и там это еще можно понять.<br> https://opennet.ru/openforum/vsluhforumID3/129098.html#160 Sun, 04 Dec 2022 01:17:55 GMT &gt; WD Purple никогда не были с записью SMR, подробнее здесь<br><br>Забавный зверек. Если бы не было написано CMR я бы подумал что ОНО именно черепица: здоровенный буфер, солидная емкость, характерные атрибуты черепичных на месте. Отдельный тролфейс на уточнение про окисление компонентов. Я знаю о чем WD говорит, экономисты фиговы, теперь вот даже в буклетиках отмазываются :)<br><br>&gt; NTFS это не требует и все работает<br><br>Вобще-то в винде не так давно был клевый баг, когда оно как раз могло урыть файлуху в хлам. И кстати, по-моему, партишн как раз прекрасно выносило, заодно с MFT - чтобы не скучно было. Так что-то типа wrap после хвоста накопителя было, со всеми вытекающими.<br><br>А вот для линуха я такого никогда не встречал, там подобные грабли оказываются именно проблемами оборудования.<br><br>&gt; Из версии в версию постоянные улучшения в ядре по файловым системам, а <br>&gt; как ломается - "это вы сами"..<br><br>В дизайне EXT4 просто нет каких-то специальных фич против разрушения. Если сравнивать с другими, типа btrfs'а какого. В самых