Александр Ларсон (Alexander Larsson), создатель Flatpak, работающий в компании Red Hat, представил предварительный вариант патчей с реализацией файловой системы Composefs для ядра Linux. Предложенная файловая система напоминает Squashfs и также подходит для монтирования образов в режиме только для чтения. Отличия сводятся к обеспечению в Composefs эффективного совместного хранения содержимого нескольких примонтированных дисковых образов и поддержке проверки подлинности читаемых данных. В качестве областей применения, в которых может оказаться востребована ФС Composefs, называется монтирование образов контейнеров и применение для Git-подобного репозитория OSTree...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58212
> первичным идентификатором является не имя файла,
> а хэш от содержимого файла.Так то идея хорошая, но если скажем в файле 80% блоков как у соседа, блочная дедупликация их уберет, а вон то разумеется в пролете, файло должно точно совпадать.
Ты понимаешь как работает хэш? Например, SHA-256?
> Ты понимаешь как работает хэш? Например, SHA-256?Да. Можно делать независимый хэш на каждый блок ФС. При обнаружении совпадения с другим заменять на реф. Чем дедубликаторы и занимаются в ФС которые умеют в cow. Отсюда жор памяти онлайн дедупом: для скорости записи список хешей известных блоков должен быть в RAM. Офлайн дедубликаторы могут позволить себе хранить это в скоростной БД, .
Когда у файла 80% блоков совпадает, эти блоки БУДУТ заменены на референсы. Это прекрасно работает с образами виртуалок из 1 шаблона, разными версиями данных с общим предком и проч. А если в имени файла закодирован весь хэш всего файла - глобальный sha файлов все же разный, вон то уже не сработает. Будет 2 полностью разных файла.
> Когда у файла 80% блоков совпадает, эти блоки БУДУТ заменены на референсы.
> Это прекрасно работает с образами виртуалок из 1 шаблона, разными версиями
> данных с общим предком и проч. А если в имени файла
> закодирован весь хэш всего файла - глобальный sha файлов все же
> разный, вон то уже не сработает. Будет 2 полностью разных файла.Читай внимательно: хэш считается у блоков. Если меняется какая-то часть -- только это блок будет посчитан заново и ссылка будет заменена новым хэшем. Все остальные блоки (и хэши) останутся прежними). Если 80% блоков общие -- откуда жор памяти? А таблица страниц памяти -- жор в памяти не устраивает?
Опять херню, которая нужна <0.01% пользователей, запихают в ядро, чтоб в следующем релизе ядра гордиться количеством добавленных строчек кода, мол, ого-го сколько мы сделали. Давайте, ещё больше и жирнее делайте ядро!
> создатель FlatpakНичего не говорит? Ясно же, вся эта штука для того чтоб шарить файлы между пакетами.
> чтоб шарить файлы между пакетамиshared library? Ой, где-то мы это уже слышали...
Слышал звон.. Вначале разберитесь, что такое FlatPak и по какому принципу он работает
>Вначале разберитесь, что такое FlatPak и по какому принципу он работаетпо такому, который не нужен
Да, в описании flatpak.
Нет. Не шаред мемори. Речь идёт про дедупликацию файлов с одинаковым содержимым, где вместо имени -- хэш. Файлы могут быть чем угодно -- например, пять электронов, десять хромов и 20 фарефоксов. По факту -- всё будет в одном экземляре. Но к хэшу будет прикручено соответствующее количество ссылок.
Ну как бы если кому не надо а жирнота парит - может модуль с ней и не собирать. Впрочем даже если он и соберется, то не будет загружен покуда не попадется диск с такой файлухой, а плюс-минус сколько-то килобайт в /lib/modules не похрен ли сейчас, кроме совсем уж мелочи типа роутеров с openwrt?Гораздо хуже когда что-то такое понадобилось - а его нет. Вот тут уже мелкими фокусами не отвертишься.
новость > монтирование образов контейнеровиксперт опеннет> херню, которая нужна <0.01% пользователей
Так и есть.
Интересно, а как вы используете ядро, и нововведения влияют на лично ваше использование системы?
внутривенно
Контейнеры, атомарные дистрибутивы, flatpak/snap. Все что сейчас на хайпе у авангарда дистроделов.
> нужна <0.01% пользователей, запихают в ядроОн скорее будет как модуль ядра, как и все стопитсот драйверов от всего что угодно
Если "эта херня" уменьшит размер тех же флатпаков - уже плюс.Понятно, что растекание жира по диску надо бы решать кардинально по другому, но маховик всех этих контейнеровозов уже работает на полную, не остановишь.
>но маховик всех этих контейнеровозов уже работает на полную, не остановишь.не работай где это требуют. ну можно какую-нибудь хиппочухню навроде mailcow или redmine в докере развернуть, а почти всё остальное нет )
Очередной эксперт опеннет, отрицающий реальность.
Отменяющий реальность.
а ты не в кол-ве пользователей меряй, в доходах от продажи продуктов, для которых сабж нужен клиентам.
> создатель Flatpak, работающий в компании Red Hat,Бинго.
Скажи спасибо что не snap-а.
Сорта
> В Composefs применяется модель хранения с адресацией на основе содержимого, т.е. первичным идентификатором является не имя файла, а хэш от содержимого файлаДля подобной фичи ZFS требуется дофига памяти.
в zfs блочная дедупликация, тут всего файла целиком. 1 бит отличается на 100 мбайт - хэш всего файла в 100 мбайт отличается, пролет.
Нет.
В ZFS хешируются записи, которые имеют дефолтный размер до 128кб, но могут быть размером до 1мб и больше.
Так вот, если файл меньшего размера чем размер записи в свойствах датасета, то хеш будет всего файла.
В btrfs по минимуму можно и 4К блоками офлайн дедуп сделать. Если вас не задолбает столько хешей хранить и процессить конечно, это некий выбор между полнотой дедупликации и ресурсов потраченых на процедуру, чем точнее тем больше ресурсов надо просадить на это. Ну и куча рефов на 4К блоки с именно такой размерностью адресации не очень эффективно по оверхеду может быть. В зависимости от глупизны дедубликатора он может слить идентичные регионы вместе но даже так есть риск получить кучу мелочи и метаданных на вот это все.
> В btrfs по минимуму можно и 4К блоками офлайн дедуп сделать.Ну и зачем ты всё это писал.
Речь идёт про zfs.
Захайлайтить достоинства дизайна относительно ZFS - пойдет? :)
не пойдёт, в ZFS и 512 байт можно.
Я не спец по ZFS, но мне кажется там речь шла про онлайн-дедупликацию?
А тут дедупликация уже сделана, ф/с же read only. Ресурсы были потрачены при сборке образа фс, а сейчас читай себе из готового индекса и горя не знай.
Он просто тупо хейтит не разобравшись.
А что, можно было как-то по-другому?
Можно было хейтить разобравшись.
Слишком сложно, так никто не делает.
> Слишком сложно, так никто не делает.А давайте вы не будете говорить за всех
Так не бывает.
«при сборке образа»... Речь идёт о дедупликации между образами.
> А тут дедупликация уже сделана, ф/с же read only. Ресурсы были потрачены при сборке образа фс, а сейчас читай себе из готового индекса и горя не знай.И спроси себя сам: а нахрена для этого нужна новая ФС на стороне ядра?
> И спроси себя сам: а нахрена для этого нужна новая ФС на стороне ядра?Для скорости и минимума оверхеда. Файловые операции реализует ядро.
Для btrfs есть "офлайн" дедупалки с куда более разумным потреблением, но это не в реалтайме, для "холодных" данных актуальнее.
Для какой фичи?
Ты, наверное, имел ввиду дедупликацию, но по незнанию сморозил фигню?
В ZFS хешами обложено всё что можно, а вот память в ней жрёт ARC (кэш), отключи и жрать не будет.
Раньше при дедупликации требовалось много памяти для хранения таблицы, но это починили.
Слишком много компотфсов.
В погоне за копеечной экономией места на хранилках (основное всё равно данные весят) шагнули куда-то совсем не туда.
Люблю эти разговоры о месте и памяти. В комментариях их всегда навалом и они всегда дёшевы и в тех же самых комментариях жалуются на объёмы их потребления и что новая память ещё дорогая.
Какая она нафиг дорогая, её сейчас просто задом есть можно, ну, если на электронах буизнес-попликухи не писать конечно.
Когда не знаешь, что кроме десктопов есть ещё огромный рынок серверов и ДЦ
Я как раз про серверы и ДЦ, т.к. они мне ближе, чем десктопы.
Любитель позапускать электроны на серверах?)
> Какая она нафиг дорогая, её сейчас просто задом есть можно, ну, если
> на электронах буизнес-попликухи не писать конечно.Именно так расскждают макакокодеры-смузисосы и крапают свою блоатварь не оглядываясь на потребление и оптимизацию, будто только их крап будет единственным работать в системе, но сюрприз-сюрприз, т.к. подобных макак овердофига, каждый крапает свой крап и от этого системы пухнут, как дрожжи в сельском сортире, с соответствующим эффектом. В итоге, получаем такие системы, даже установщик которых еле справляется влезать в 4Гб ОЗУ. А всякие эти говноснапы и флатпаки почём зря выжирают ресурсы системы.
Но смузисосам же пофиг, память - копеечная, все кому надо купят, а остальные - нищeбpoды.
Вот только так для всего, сраный калькулятор в современных системах весит и жрёт столько, сколько раньше игры полноценные потребляли, а меж тем, возможности самого калькулятора не изменились с годами, порой даже наоборот, инженерной опции в них нет.Взять бы этих макак, да пересадить на сетапы с 2Гб ОЗУ и заставить писать только в таких условиях, а кто не справился - того на мороз, вот тогда был бы толк, а сейчас просто быдлокодинг хипсторский, зато можно в антикофе зависать, ездить на гироскутерах, электросамокатах и вейп сосать со смузи, прогая на линуксы с маков.
Прочитал твою телегу и хочется сказать «бро, поддержка и сочувствие». Как говорят сейчас в интернете: «эти смузисосы сейчас здесь, в этой комнате?»Видно, что тебе плохо; возможно, из-за что в детстве были телесные наказания или травля. Ты кипишь из-за того, что некие «смузисосы» где-то плохо пишут код и тратят некую память, из-за вымышленной в общем-то ситуации. Ведь ни твой сосед не тратит память на твоём компьютере, ни твой коллега не тратит память на сервере компании, ни в твой проект смузисос не комитит говно.
Думаю, за фигурой «смузисосов», которые всё делают из рук вон плохо скрывается родитель или кто-то другой, на кого у тебя обида и злость, но кого критиковать и ругать нет возможности/прав/смелости, вот ты и переносишь свой гнев.
Повторюсь, поддержка и сочувствие, бро.
Просто отлично сказано!
Это просто убогий человек, озлобленный на жизнь.
Какой же убогий со своей злостью.
>если на электронах буизнес-попликухи не писать конечно.Это не тебе решать, а энтерпрайзу, которому чем больше потребление памяти у быдла, тем лучше, ибо тем больше прибыли получат производители памяти (а куда быдло денется с подводной лодки, побежит в магаз как миленькое!), тем больше они смогут инвестировать в R&D, тем больше будет прогресс в росте объёмов памяти, тем быстрее старые компы устареют, станут неюзабельны и пойдут на свалку, тем больше в новых будет память, тем больше можно будет пренебречь пользователями старых компов (тех, которых ПОКА ЧТО выбросить нельзя, а не тех, кого уже выбросили на свалку к бомжам), тем более дешёвых макак можно будет нанять для написания программ на Электроне.
>[оверквотинг удален]
> Это не тебе решать, а энтерпрайзу, которому чем больше потребление памяти у
> быдла, тем лучше, ибо тем больше прибыли получат производители памяти (а
> куда быдло денется с подводной лодки, побежит в магаз как миленькое!),
> тем больше они смогут инвестировать в R&D, тем больше будет прогресс
> в росте объёмов памяти, тем быстрее старые компы устареют, станут неюзабельны
> и пойдут на свалку, тем больше в новых будет память, тем
> больше можно будет пренебречь пользователями старых компов (тех, которых ПОКА ЧТО
> выбросить нельзя, а не тех, кого уже выбросили на свалку к
> бомжам), тем более дешёвых макак можно будет нанять для написания программ
> на Электроне.Именно так.
Приятно видеть адекватного брата Анонима на опеннете, я бы поставил плюс, но Анонимов тут угнетают, поэтому только так: +
иксперт опеннет> шагнули куда-то совсем не туда.значит все правильно делают
А, да пользуйтесь, не обляпайтесь только.
Фейспалм. Прочти новость и о назначение этой read only файловой системы.
Так ты сам разобрался зачем (низачем) она тебе?
У меня тут файл на пару терабайт, и я в него иногда пару байтиков дописываю.О да! Хэшируй меня полностью, да еще и в много потоков!
Да ладно, главное ж - еканомия.
Кстати с дозаписью запросто решается сохранением промежуточных стейтов, главное - в серёдку не писать :D
Скользящий хеш вроде Рабина спасет гиганта мысли.
А если совсем делать нехрен то что-то типа меркловского дерева сильно ограничит объем хеширования. Ну то-есть рехэш измененного блока + хэшей уровнями выше, вполне разумный объем будет.
А тебя заставили эту fs использовать? А, не, погоди, ты же не умеешь выбирать fs для своих целей, сорри
> У меня тут файл на пару терабайт, и я в него иногда
> пару байтиков дописываю.Всё нормально будет дедуплицироваться, Composefs работает в режиме read only, а запись реализуется через overlayfs. Исходные файлы образа остаются всегда постоянными.
Ага, давайте хранить террабийтные файлы в fs узкого назначения
> подходит для монтирования образов в режиме только для чтения
> У меня тут файл на пару терабайт, и я в него иногда пару байтиков дописываю.Ох уж эти опеннет иксперты™
Для того эксперта могу сказать что на btrfs это вполне нормально работает. Можно пройтись fsck'ом на "reflinked" копии, те пара или сколько там байтиков запишутся в сторонку CoW, остальные "почти пара терабайт" так и останутся расшареными на двоих. И все это просто, быстро, эффективно и абсолютно прозрачно для софта, который видит якобы 2 совершенно независимые 2-терабайтные файлы. Дедупать 2 терабайта конечно жестковато по ресурсам, в этом месте идея сразу при "копировании" хинтить что это полный дедуп (reflink) как раз очень круто получается.
И ты для этого собираешься использовать файловую систему, сделанную специально для использования в readonly. Ну, наверное.Верни мне веру в опеннетовских аналитиков, напиши просто, что ты не прочитал исходное сообщение.
Про сквошФС ты, конечно, строку пропустил?
> создатель FlatpakИ дальше можно не читать. Знак антикачества.
это ты еще snap не видел
> 5 Done today at 15:53 +07 today at 15:53 +07 Remove inactive vulnerable "snapd" snap (17576)Вот это инновации, SNAP удаляет уязвимые эти самые 😮
Думаю, полезно и не для контейнеров. Хочу shuashfs с дедупликацией для архивов и резервных копий, а это оно и есть по сути дела.
https://github.com/restic/restic/blob/master/doc/design.rstНе оно?
> https://github.com/restic/restic/blob/master/doc/design.rst
> Не оно?Нельзя примонтировать, как сквош. Можно в принципе сделать файл-образ BTRFS, а внутри него сжатие и оффлайн-дедупликацию.
И даже можно сделать ридонли базу, например оформив как seed-девайс. Или просто флаг readonly на снапшоте который считаем основой. Смотря насколько близко поведение сквоша имитировать хотелось.
DWARFS
Охренеть, список зависимостей на экран не лезет, и они имеют наглость вперев все вплоть до питонов себя с сквошом сравнивать. Жэсть!
> Охренеть, список зависимостей на экран не лезет, и они имеют наглость вперев
> все вплоть до питонов себя с сквошом сравнивать. Жэсть!Сравнение с squashfs проводится по производительности и степени сжатия данных. Метрика "количество зависимостей" информативной не является, особенно без разделения на зависимости времени сборки и зависимости времени исполнения, и последних там совсем немного.
Хотя кому я это рассказываю, местные клоуны новость прочитать не в состоянии.
> Сравнение с squashfs проводится по производительности и степени сжатия данных. Метрика
> "количество зависимостей" информативной не является, особенно без разделения на зависимости
> времени сборки и зависимости времени исполнения, и последних там совсем немного.Вообще-то очень информативно: squashfs мы прикрутить к вон тому роутеру можем, и это будет компактно, просто и эффективно.
А вон тот переросток с питонами-электронами в фузе туда чисто технически не уместится и благодать не наступит. Да и фуз на файловых операциях проц грузит мама не горюй, естественно, от паттернов доступа очень зависит.
Используй Borg. Без шуток.
> даёт возможность экономить как дисковую, так и оперативную память.Зато проц нагнёт, нормальная такая экономия ресурсов.
С чего бы, если дедуплицируется один раз при монтировании?
> Отличия сводятся к обеспечению в Composefs эффективного совместного хранения содержимого нескольких примонтированных дисковых образовТ.е. эта экономия не про "место на жёстком диске", а только про оперативку?
> Подобная модель обеспечивает дедупликацию и позволяет фактически хранить только одну копию одинаковых файловЕсли одинаковые файлы изначально идут с разных "примонтированных дисковых образов", о какой дедупликации тогда речь?
> одинаковые файлы изначально идут с разных "примонтированных дисковых образов", о какой
> дедупликации тогда речь?Каждый образ в Composefs состоит из двух частей - сам образ только с метаданными и отдельное, общее для всех образов, хранилище данных, т.е. метаданные для всех образов разделены, а содержимое файлов свалено в общую кучу.
Монтируется как-то так
mount /путь/к/образу/с/метадаными -t composefs -o basedir=/путь/к/хранилищу/содержимого /mnt
basedir нужно весь целиком держать с самого начала или можно пополнять по мере надобности?
> общее для всех образов, хранилище данныхи много есть образов с большими одинаковыми файлами на _одном_ физическом носителе?
Да. Например, в NixOS (оптимизируется хардлинками), да и в любой OSTree-like иерархии. Для дистрибутивов родом из 90х это, конечно же, не актуально.
>Например, образы контейнеров содержат множество типовых системных файлов и в случае применения Composefs каждый из этих файлов будет совместно использован всеми примонтированными образами, без применения трюков, таких как проброс при помощи жёстких ссылок. При этом общие файлы не только хранятся в виде одной копии на диске, но и обходятся одной записью в страничном кэше, что даёт возможность экономить как дисковую, так и оперативную память.Вспоминая про "безопасность" контейнеров, очень быстро найдутся умельцы которые с обновлением своего супер-мега контейнера подсунут в basedir либы с бекдорами, которые подтянутся другими контейнерами и вот вам готовая дырень.
Оно ещё в релиз не пошло, а вы уже палите, нехорошо.
> с обновлением своего супер-мега контейнера подсунут в basedir либы с бекдорами, которые подтянутся другими контейнерамиКак они потянутся, если у них будет свой собственный уникальный хеш, который не используется другими контейнерами?
Остапа понесло...хepню сморозил...каюсь
Для NixOS по идее тоже должно работать?
Зачем? Вы ext4 надёжней сделайте.
Есть терабайтный диск с ext4, которая стала raw. Testdisk не нашел даже загрузочной записи, dmde и rlinux тоже ничего не нашли.
Отключал через безопасное отключение.
Теперь диск, отработавший всего 1022 часа, отправится в мусор, а вы так и будете клепать новые файловые системы..
Рейд-контроллер без барьеров и батарейки - мечта мазохиста?
Рейд для одного диска?
> Теперь диск, отработавший всего 1022 часа, отправится в мусорЯдро 5.19.* ? Если нет, то кто производитель диска?
WD Purple
Использовался только для хранения видео
ссзб кмк, wd пихают хлам как диски для видеонаблюдения (маленьким шрифтом подписано что для холодного хранения), а железо там обычная блюшка с другой прошивкой. Надо брать ынтерпрайз диски.
Да явно диск плохой. Я практически не пользуюсь безопасными отключениями ext4, и ничего страшного не происходит же. А компов у меня... много всяких.
Точно! Диск виноват. Только под windows и с ntfs диск работал без проблем, а в linux и с ext4 через раз определялся.
Но виноват диск, конечно..
> Только под windows и с ntfs диск работал без проблем, а в linux и с ext4 через раз определялся.Говорили мне не выноси мусор на ночь, примета плохая. Не послушал. Теперь и войны и санкции.
Ну, совпадение же.Вот если бы у Вас, или у кого то то же самое массово с ССД повторялось, то об проблеме давно бы знали.
А пока подобное не подтверждается, и SSD с ext4 работают хорошо.Да и упомянутый ресурс мизерный для любого использования, даже для дешевого SSD.
Остается только думать на брак.
Давно ли WD стала выпускать SSD под маркой WD Purple?
> Давно ли WD стала выпускать SSD под маркой WD Purple?Он поди был видным представителем черепичных, как большинство современных винчей с соблазнительной ценой за гиг. И, вероятно, отступить от партишн тэйбла немного чтобы оставить его в покое гражданин не догадался. Ну а при факапе GC наверное и улетел партишн заодно. Вот чего-чего а такое счастье при неумном раскладывании ФС бывает довольно регулярно.
Если повезет - можно вернуть партишн и недурно восстановится, если улетело только это. Если что-то еще - смотря что улетело. Ну вон у btrfs допустим суперблоков как правило 3 копии, все сразу все же не улетают, а если еще и DUP метаданных был (чаще всего есть) есть нехилый шанс это смонтировать потом. А ext4 никогда и не делали с прицелом на надежность, там как повезет. Хотя вот именно совсем наповал его убить еще постараться надо.
> Он поди был видным представителем черепичныхWD Purple никогда не были с записью SMR, подробнее здесь
https://u.to/5CJ4HA
> отступить от партишн тэйбла немного чтобы оставить его в покое гражданин не догадалсяNTFS это не требует и все работает
> ext4 никогда и не делали с прицелом на надежностьИз версии в версию постоянные улучшения в ядре по файловым системам, а как ломается - "это вы сами"..
> WD Purple никогда не были с записью SMR, подробнее здесьЗабавный зверек. Если бы не было написано CMR я бы подумал что ОНО именно черепица: здоровенный буфер, солидная емкость, характерные атрибуты черепичных на месте. Отдельный тролфейс на уточнение про окисление компонентов. Я знаю о чем WD говорит, экономисты фиговы, теперь вот даже в буклетиках отмазываются :)
> NTFS это не требует и все работает
Вобще-то в винде не так давно был клевый баг, когда оно как раз могло урыть файлуху в хлам. И кстати, по-моему, партишн как раз прекрасно выносило, заодно с MFT - чтобы не скучно было. Так что-то типа wrap после хвоста накопителя было, со всеми вытекающими.
А вот для линуха я такого никогда не встречал, там подобные грабли оказываются именно проблемами оборудования.
> Из версии в версию постоянные улучшения в ядре по файловым системам, а
> как ломается - "это вы сами"..В дизайне EXT4 просто нет каких-то специальных фич против разрушения. Если сравнивать с другими, типа btrfs'а какого. В самых последних версиях правда сделали чексумы журнала, кажется, чтобы оно совсем уж вдрызг не дестроило ФС при отклонении от идеала. Но если у кого партишн слетел, там дело явно не в ФС. Ну вот не трогают ФС партишн при нормальной работе. Незачем оно им. Значит что-то пошло сильно не так на другом уровне.
А ext4 тут причём, если диск сдох? Ты можешь доказать, что ext4 убила диск? Ждём твои сенсационные заявления в багтрекере ядра.
Ты криворучка. Ехт4 вполне тупая фс, которую можно вручную без драйвера разобрать, не говоря уже о photorec. Ещё у неё суперблок бекапится в разных частях диска. Зная где, можно примонтировать с бекапом.
Диск не определяется в этих ваших "супер программах" типа photorec и testdisk! Как узнать где этот суперблок?
Ты лучше бы читать научился..
>Теперь диск, отработавший всего 1022 часа, отправится в мусорТ.е., в основе проблема аппаратная? Тогда вопросы к произодителю диска.
Диск отработавший 1022 часа через "безопасное отключение" стал raw вместо ext4 и теперь программами testdisk и dmde не находится даже суперблок, не говоря уж о резервном загрузчике..
> Диск отработавший 1022 часа через "безопасное отключение" стал raw вместо ext4 и
> теперь программами testdisk и dmde не находится даже суперблок, не говоря
> уж о резервном загрузчике..Так на диске то что в результате? Таблица разделов есть? Какие-то правдоподобные данные остались? Если б вы NTFS сказали - окей, для него MS не так давно признавал такой факап, требующий определенных условий, их дожали после того как у юзеров сыпучка стала массово случаться. Но в линухе вот именно такой грабли не припоминается. Там откровенная сыпучка разве что у вон тех энтерпрайзников бездумно кладущие кеши на SSD, а когда тот протирается и продалбывает несколько крупных блоков - ну, ок, это превышает допущения большинства ФС и там это еще можно понять.
> MS не так давно признавал такой факап, требующий определенных условийСсылка на источник тоже имеется?
> откровенная сыпучка разве что у вон тех энтерпрайзников бездумно кладущие кеши на SSDWD никогда не выпускала SSD под маркой Purple. Пометь уже там в своей методичке..
Т.е. у тебя умер контроллер, но виновата ext4?.... Ок
> Зачем? Вы ext4 надёжней сделайте.И запретите производить сыпучие диски, да?
> Есть терабайтный диск с ext4, которая стала raw. Testdisk не нашел даже
> загрузочной записи,И как тебе ext4, интересно, виноват в том что у тебя, буратины, таблица разделов слетела? Это проблема на твоей стороне, либо на стороне девайса. То-есть либо у тебя железо фигню творит и вот так вот запросто может таблицу разделов снести, либо это был SSD и ты очень глупо разложил ФС на нем - не сделав отступ от таблицы разделов хотя-бы мега на 32, чтобы оставить партишн в "холодном" блоке флеша который ФС при нормальной работе не трогает. А когда контроллер SSD полез ворочать огромный блок флеша и облажался, он не только что-то от ФС продолбал но и таблицу разделов заодно. EXT4 про это все вообще ничего не знал, разумеется.
Вариантов у тебя немного. Ты либо можешь пересоздать таблицу разделов ручками, точно угадав границы. Или если кишка тонка, развлекайся photorec'ом или коммерческими утилитами выковыривая уже продвинутым сканированием. В любом случае это косяк тебя и твоего железа. Таблица разделов слетать не должна и от надежности EXT4 это не зависит - EXT4 сам по себе таблицу разделов не трогает вообще.
> Теперь диск, отработавший всего 1022 часа, отправится в мусор, а вы так
> и будете клепать новые файловые системы..И что характерно, файловые системы вообще таблицы разделов не трогают в общем случае. Не их прерогатива.
WD не изобрела ещё SSD под маркой Purple..
Это все, что нужно знать о местных экспертах..
> WD не изобрела ещё SSD под маркой Purple..Увы, сообщения нельзя редактировать, я про Purple позже нашел. Оно, вроде, черепица, так что идея почему оно могло слететь - похожая. Неудачный GC в области с партишном - и гудбай партишн.
> Это все, что нужно знать о местных экспертах..
Ну вы то покажете мастеркласс?
> Оно, вроде, черепицаВсе ответы здесь https://u.to/5CJ4HA
> Ну вы то покажете мастеркласс?Ну если вы не знаете, что WD никогда не выпускала SSD под маркой Purple и что WD Purple не выпускались с записью SMR, то это говорит, что вы не очень-то и разбираетесь - все на предположениях..
Теоретически, оттуда следует что это обычный диск с 4К секторами. Не очень понятно как и почему он партишн потерял, или что под "raw диском" имелось в виду?> то это говорит, что вы не очень-то и разбираетесь - все на предположениях..
WD понаплодили линеек, да. А то было похоже на "крупноблочный облом". Но видимо не оно. В природе много странной ерунды, однако я уверен что слет партишна не является нормальным состоянием дел и EXT4 в этом не замечен. Как и вообще в внезапных харакири без причин. Если б вы это про NTFS сказали - там MS удалось вычислить в определенном случае, после начала массовых осыпонов. Но вон то является чем-то довольно нетипичным. И больше всего похоже на кривую работу железа.
А чё с лицом?
https://www.cnews.ru/news/top/razrabotchiki_ubuntu_priznali_...
Файловые системы в век SSD не нужны! SSD вполне себе может работать по принципу RAM.
Программы в век компьютеров не нужны! Компьютеры вполне себе могут работать по принципу ЦПУ.
А без файловой системы Вы файлы то куда деваете?А cо стиранием страницами и ограниченным ресурсом SSD может работать по принципу RAM весьма недолго, для избежания чего и нужны оптимизированные для SSD файловые системы.
Речь не про твоё старьё на SATA интерфейсе. Речь про нормальный человеческий NVMe.
>А без файловой системы Вы файлы то куда деваете?Раз SSD в качестве RAM, то в RAM создаётся рамдиск :)
Не стыдно сидеть на компьютерном форуме и не знать как компьютер работает с памятью? Наверное все твои знания сводятся к командам git и npm.
А тебе лень глаза вверх на несколько постов поднять, чтоб сообразить, на какую заяву был ответ?
>>А без файловой системы Вы файлы то куда деваете?
> Раз SSD в качестве RAM, то в RAM создаётся рамдиск :)Рамдиск тоже требует созданния на нём какой нибудь файловой системы.
И требует файловой системы везде, и на Linux, Windows, и на микроконтроллере, и даже на древнем ZX Spectrum.
Иначе останется блочным устройством для RAW операций :)
> Файловые системы в век SSD не нужны! SSD вполне себе может работать
> по принципу RAM.А отсылать в конкретный файл как предлагается? Прямо по физическому/логическому адресу? Даешь hexspeak в массы! :)
Объясните олдскульщику, зачем нужна файловая система, которая постоянно считает хеши? Она ведь будет тормозить, а в случае коллизии, гарантии от которой нет никакой, накроется тазом.
Она не считает хеши. Вернее, считает, но в основном использует готовые хеши из индекса. При этом она иммутабельная, так что пересчитывать ничего не нужно.
> пересчитывать ничего не нужнообновил мету в фильме - ой... оказывается, надо.
> для монтирования образов в режиме только для чтения
> обновил мету в фильмеНовость не читай, сразу коммент пиши! Эксперды опеннета в своём обычном амплуа.
Для Flatpak, чтоб все данные в одну гигантскую кучу намешать.
Она не постоянно их считает. Почитайте про принцип contrnt-adressable, в этом подходе мы заранее знаем что хотим, и запрашиваем вот именно это самое, окончательным идентификатором является хэш контента. Ну то-есть abcd.so -> (имя файла) a1b2c3....ef -> данные.А то что кто-то там сто лет назад посчитал хэш(данные) и разложил его в файло с именем a1b2c3....ef потому что хэш такой, не обязывает его пересчитывать постоянно.
Объясняю школьному одскульщику: ФС в режиме "только для чтения" не имеет изменяющихся частей. Хэш посчитали за тебя и даже не на твоём компьютере. Твои затраты минимальны. А выигрышь по занимаемому месту -- может оказаться от десятков процентов до кратных величин. ИМХО, не плохая прибавка к пенсии.
Только вот сделана эта фс специально под fs-verify который будет хэши считать постоянно.
> Только вот сделана эта фс специально под fs-verify который будет хэши считать
> постоянно.Для чего хэши считать постоянно? Ещё раз: эта файловая система монтируется в режиме "только для чтения".
>> Только вот сделана эта фс специально под fs-verify который будет хэши считать
>> постоянно.
> Для чего хэши считать постоянно? Ещё раз: эта файловая система монтируется в
> режиме "только для чтения".Для валидации данных очевидно. Все данные на оригинальной фс остаются в режиме записи.
Посмотрев на авторов становится очевидно что composefs скрестят с ostree хранилищем и получат подписанные образы на базе произвольного стора, которые можно будет встроить в secureboot цепочку(тут валидация и становится актуальной). Всё это актуально для silverblue подобных дистров.
Flatpak критиковали за прожерливость диска, вот решение. И мне нравятся контейнеры, когда приложение не "размазывается" по всей системе и можно ограничить доступ, к сети, каталогам, дискам и тд.
Тот же Steam по этим соображениям лучше ставить в контейнер, чтобы игры не шарились где непоподя. У меня 2 стима, один из пакетов, второй во flatpak, там устанавливаю все подряд, ибо встроенные зловреды в игры вполне реальная вещь.
На размер данных на диске это никак не повлияет.
*для флатпака
Проблема всяких паков не только в том, что место транжирится, но и в том что либы не обновляются.
Зачем, если есть exet4?
Круто. Давно пора. И с торрентами скрестить чтобы публично-доступные файлы было можно искать и качать по хэшу.
> Круто. Давно пора. И с торрентами скрестить чтобы публично-доступные файлы было можно
> искать и качать по хэшу.Это eMule/aMule называлось и вот именно публиковало файло из дир по вот именно их хэшу, при том все кто с одинаковыми файлами автоматически находились :)