1.1, Аноним (-), 23:06, 28/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> первичным идентификатором является не имя файла,
> а хэш от содержимого файла.
Так то идея хорошая, но если скажем в файле 80% блоков как у соседа, блочная дедупликация их уберет, а вон то разумеется в пролете, файло должно точно совпадать.
| |
|
|
3.145, Аноним (-), 18:17, 01/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Ты понимаешь как работает хэш? Например, SHA-256?
Да. Можно делать независимый хэш на каждый блок ФС. При обнаружении совпадения с другим заменять на реф. Чем дедубликаторы и занимаются в ФС которые умеют в cow. Отсюда жор памяти онлайн дедупом: для скорости записи список хешей известных блоков должен быть в RAM. Офлайн дедубликаторы могут позволить себе хранить это в скоростной БД, .
Когда у файла 80% блоков совпадает, эти блоки БУДУТ заменены на референсы. Это прекрасно работает с образами виртуалок из 1 шаблона, разными версиями данных с общим предком и проч. А если в имени файла закодирован весь хэш всего файла - глобальный sha файлов все же разный, вон то уже не сработает. Будет 2 полностью разных файла.
| |
|
4.168, Брат Анон (ok), 13:37, 05/12/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Когда у файла 80% блоков совпадает, эти блоки БУДУТ заменены на референсы.
> Это прекрасно работает с образами виртуалок из 1 шаблона, разными версиями
> данных с общим предком и проч. А если в имени файла
> закодирован весь хэш всего файла - глобальный sha файлов все же
> разный, вон то уже не сработает. Будет 2 полностью разных файла.
Читай внимательно: хэш считается у блоков. Если меняется какая-то часть -- только это блок будет посчитан заново и ссылка будет заменена новым хэшем. Все остальные блоки (и хэши) останутся прежними). Если 80% блоков общие -- откуда жор памяти? А таблица страниц памяти -- жор в памяти не устраивает?
| |
|
|
|
1.2, ИмяХ (?), 23:14, 28/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +17 +/– |
Опять херню, которая нужна <0.01% пользователей, запихают в ядро, чтоб в следующем релизе ядра гордиться количеством добавленных строчек кода, мол, ого-го сколько мы сделали. Давайте, ещё больше и жирнее делайте ядро!
| |
|
2.6, Аноним (6), 23:29, 28/11/2022 [^] [^^] [^^^] [ответить]
| +15 +/– |
> создатель Flatpak
Ничего не говорит? Ясно же, вся эта штука для того чтоб шарить файлы между пакетами.
| |
|
3.52, Аноним (52), 08:12, 29/11/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
> чтоб шарить файлы между пакетами
shared library? Ой, где-то мы это уже слышали...
| |
|
4.83, Аноним (83), 16:20, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Слышал звон.. Вначале разберитесь, что такое FlatPak и по какому принципу он работает
| |
|
5.85, лютый ж.... (?), 16:42, 29/11/2022 [^] [^^] [^^^] [ответить]
| –6 +/– |
>Вначале разберитесь, что такое FlatPak и по какому принципу он работает
по такому, который не нужен
| |
|
4.129, Брат Анон (ok), 16:23, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Нет. Не шаред мемори. Речь идёт про дедупликацию файлов с одинаковым содержимым, где вместо имени -- хэш. Файлы могут быть чем угодно -- например, пять электронов, десять хромов и 20 фарефоксов. По факту -- всё будет в одном экземляре. Но к хэшу будет прикручено соответствующее количество ссылок.
| |
|
|
2.12, Аноним (12), 00:15, 29/11/2022 [^] [^^] [^^^] [ответить]
| +4 +/– |
Ну как бы если кому не надо а жирнота парит - может модуль с ней и не собирать. Впрочем даже если он и соберется, то не будет загружен покуда не попадется диск с такой файлухой, а плюс-минус сколько-то килобайт в /lib/modules не похрен ли сейчас, кроме совсем уж мелочи типа роутеров с openwrt?
Гораздо хуже когда что-то такое понадобилось - а его нет. Вот тут уже мелкими фокусами не отвертишься.
| |
2.15, Аноним (15), 00:27, 29/11/2022 [^] [^^] [^^^] [ответить]
| +9 +/– |
новость > монтирование образов контейнеров
иксперт опеннет> херню, которая нужна <0.01% пользователей
| |
2.23, Аноним (23), 01:04, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Интересно, а как вы используете ядро, и нововведения влияют на лично ваше использование системы?
| |
2.50, Аноним (50), 08:06, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Контейнеры, атомарные дистрибутивы, flatpak/snap. Все что сейчас на хайпе у авангарда дистроделов.
| |
2.63, . (?), 10:16, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> нужна <0.01% пользователей, запихают в ядро
Он скорее будет как модуль ядра, как и все стопитсот драйверов от всего что угодно
| |
2.72, Константавр (ok), 12:43, 29/11/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если "эта херня" уменьшит размер тех же флатпаков - уже плюс.
Понятно, что растекание жира по диску надо бы решать кардинально по другому, но маховик всех этих контейнеровозов уже работает на полную, не остановишь.
| |
|
3.86, лютый ж.... (?), 16:44, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
>но маховик всех этих контейнеровозов уже работает на полную, не остановишь.
не работай где это требуют. ну можно какую-нибудь хиппочухню навроде mailcow или redmine в докере развернуть, а почти всё остальное нет )
| |
|
2.115, mos87 (ok), 06:44, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
а ты не в кол-ве пользователей меряй, в доходах от продажи продуктов, для которых сабж нужен клиентам.
| |
|
1.4, ip1982 (ok), 23:24, 28/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> В Composefs применяется модель хранения с адресацией на основе содержимого, т.е. первичным идентификатором является не имя файла, а хэш от содержимого файла
Для подобной фичи ZFS требуется дофига памяти.
| |
|
2.11, Аноним (11), 00:04, 29/11/2022 [^] [^^] [^^^] [ответить]
| +6 +/– |
в zfs блочная дедупликация, тут всего файла целиком. 1 бит отличается на 100 мбайт - хэш всего файла в 100 мбайт отличается, пролет.
| |
|
3.47, Минона (ok), 07:38, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Нет.
В ZFS хешируются записи, которые имеют дефолтный размер до 128кб, но могут быть размером до 1мб и больше.
Так вот, если файл меньшего размера чем размер записи в свойствах датасета, то хеш будет всего файла.
| |
|
4.146, Аноним (-), 18:37, 01/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
В btrfs по минимуму можно и 4К блоками офлайн дедуп сделать. Если вас не задолбает столько хешей хранить и процессить конечно, это некий выбор между полнотой дедупликации и ресурсов потраченых на процедуру, чем точнее тем больше ресурсов надо просадить на это. Ну и куча рефов на 4К блоки с именно такой размерностью адресации не очень эффективно по оверхеду может быть. В зависимости от глупизны дедубликатора он может слить идентичные регионы вместе но даже так есть риск получить кучу мелочи и метаданных на вот это все.
| |
|
5.153, Минона (ok), 07:05, 02/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> В btrfs по минимуму можно и 4К блоками офлайн дедуп сделать.
Ну и зачем ты всё это писал.
Речь идёт про zfs.
| |
|
|
|
2.13, Гентушник (ok), 00:17, 29/11/2022 [^] [^^] [^^^] [ответить]
| +5 +/– |
Я не спец по ZFS, но мне кажется там речь шла про онлайн-дедупликацию?
А тут дедупликация уже сделана, ф/с же read only. Ресурсы были потрачены при сборке образа фс, а сейчас читай себе из готового индекса и горя не знай.
| |
|
3.82, ip1982 (ok), 16:20, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> А тут дедупликация уже сделана, ф/с же read only. Ресурсы были потрачены при сборке образа фс, а сейчас читай себе из готового индекса и горя не знай.
И спроси себя сам: а нахрена для этого нужна новая ФС на стороне ядра?
| |
|
4.147, Аноним (-), 18:38, 01/12/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
> И спроси себя сам: а нахрена для этого нужна новая ФС на стороне ядра?
Для скорости и минимума оверхеда. Файловые операции реализует ядро.
| |
|
|
2.17, Аноним (-), 00:39, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для btrfs есть "офлайн" дедупалки с куда более разумным потреблением, но это не в реалтайме, для "холодных" данных актуальнее.
| |
2.45, Минона (ok), 07:33, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Для какой фичи?
Ты, наверное, имел ввиду дедупликацию, но по незнанию сморозил фигню?
В ZFS хешами обложено всё что можно, а вот память в ней жрёт ARC (кэш), отключи и жрать не будет.
Раньше при дедупликации требовалось много памяти для хранения таблицы, но это починили.
| |
|
1.8, Аноним (8), 23:36, 28/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Слишком много компотфсов.
В погоне за копеечной экономией места на хранилках (основное всё равно данные весят) шагнули куда-то совсем не туда.
| |
|
2.14, Аноним (14), 00:17, 29/11/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Люблю эти разговоры о месте и памяти. В комментариях их всегда навалом и они всегда дёшевы и в тех же самых комментариях жалуются на объёмы их потребления и что новая память ещё дорогая.
| |
|
3.20, Аноним (8), 00:40, 29/11/2022 [^] [^^] [^^^] [ответить]
| –3 +/– |
Какая она нафиг дорогая, её сейчас просто задом есть можно, ну, если на электронах буизнес-попликухи не писать конечно.
| |
|
|
5.76, Аноним (8), 15:57, 29/11/2022 [^] [^^] [^^^] [ответить]
| –2 +/– |
Я как раз про серверы и ДЦ, т.к. они мне ближе, чем десктопы.
| |
|
4.71, Аноним (71), 12:19, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
>если на электронах буизнес-попликухи не писать конечно.
Это не тебе решать, а энтерпрайзу, которому чем больше потребление памяти у быдла, тем лучше, ибо тем больше прибыли получат производители памяти (а куда быдло денется с подводной лодки, побежит в магаз как миленькое!), тем больше они смогут инвестировать в R&D, тем больше будет прогресс в росте объёмов памяти, тем быстрее старые компы устареют, станут неюзабельны и пойдут на свалку, тем больше в новых будет память, тем больше можно будет пренебречь пользователями старых компов (тех, которых ПОКА ЧТО выбросить нельзя, а не тех, кого уже выбросили на свалку к бомжам), тем более дешёвых макак можно будет нанять для написания программ на Электроне.
| |
|
|
2.16, Аноним (15), 00:29, 29/11/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
иксперт опеннет> шагнули куда-то совсем не туда.
значит все правильно делают
| |
2.34, Аноним (33), 03:30, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Фейспалм. Прочти новость и о назначение этой read only файловой системы.
| |
|
1.19, None (??), 00:40, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
У меня тут файл на пару терабайт, и я в него иногда пару байтиков дописываю.
О да! Хэшируй меня полностью, да еще и в много потоков!
| |
|
2.22, Аноним (8), 00:42, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Кстати с дозаписью запросто решается сохранением промежуточных стейтов, главное - в серёдку не писать :D
| |
|
|
4.98, Аноним (-), 19:56, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
А если совсем делать нехрен то что-то типа меркловского дерева сильно ограничит объем хеширования. Ну то-есть рехэш измененного блока + хэшей уровнями выше, вполне разумный объем будет.
| |
|
|
2.25, Аноним (23), 01:06, 29/11/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
А тебя заставили эту fs использовать? А, не, погоди, ты же не умеешь выбирать fs для своих целей, сорри
| |
2.46, Аноним (46), 07:35, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> У меня тут файл на пару терабайт, и я в него иногда
> пару байтиков дописываю.
Всё нормально будет дедуплицироваться, Composefs работает в режиме read only, а запись реализуется через overlayfs. Исходные файлы образа остаются всегда постоянными.
| |
2.64, another_one (ok), 10:19, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> подходит для монтирования образов в режиме только для чтения
> У меня тут файл на пару терабайт, и я в него иногда пару байтиков дописываю.
Ох уж эти опеннет иксперты™
| |
|
3.99, Аноним (-), 19:59, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Для того эксперта могу сказать что на btrfs это вполне нормально работает. Можно пройтись fsck'ом на "reflinked" копии, те пара или сколько там байтиков запишутся в сторонку CoW, остальные "почти пара терабайт" так и останутся расшареными на двоих. И все это просто, быстро, эффективно и абсолютно прозрачно для софта, который видит якобы 2 совершенно независимые 2-терабайтные файлы. Дедупать 2 терабайта конечно жестковато по ресурсам, в этом месте идея сразу при "копировании" хинтить что это полный дедуп (reflink) как раз очень круто получается.
| |
|
2.106, Admino (ok), 20:45, 29/11/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
И ты для этого собираешься использовать файловую систему, сделанную специально для использования в readonly. Ну, наверное.
Верни мне веру в опеннетовских аналитиков, напиши просто, что ты не прочитал исходное сообщение.
| |
|
|
|
3.69, iPony129412 (?), 12:03, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> 5 Done today at 15:53 +07 today at 15:53 +07 Remove inactive vulnerable "snapd" snap (17576)
Вот это инновации, SNAP удаляет уязвимые эти самые 😮
| |
|
|
1.30, mikhailnov (ok), 02:44, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Думаю, полезно и не для контейнеров. Хочу shuashfs с дедупликацией для архивов и резервных копий, а это оно и есть по сути дела.
| |
|
|
|
4.100, Аноним (-), 20:02, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
И даже можно сделать ридонли базу, например оформив как seed-девайс. Или просто флаг readonly на снапшоте который считаем основой. Смотря насколько близко поведение сквоша имитировать хотелось.
| |
|
|
|
3.101, Аноним (-), 20:04, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Охренеть, список зависимостей на экран не лезет, и они имеют наглость вперев все вплоть до питонов себя с сквошом сравнивать. Жэсть!
| |
|
4.114, qetuo (?), 05:40, 30/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Охренеть, список зависимостей на экран не лезет, и они имеют наглость вперев
> все вплоть до питонов себя с сквошом сравнивать. Жэсть!
Сравнение с squashfs проводится по производительности и степени сжатия данных. Метрика "количество зависимостей" информативной не является, особенно без разделения на зависимости времени сборки и зависимости времени исполнения, и последних там совсем немного.
Хотя кому я это рассказываю, местные клоуны новость прочитать не в состоянии.
| |
|
5.148, Аноним (-), 18:44, 01/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Сравнение с squashfs проводится по производительности и степени сжатия данных. Метрика
> "количество зависимостей" информативной не является, особенно без разделения на зависимости
> времени сборки и зависимости времени исполнения, и последних там совсем немного.
Вообще-то очень информативно: squashfs мы прикрутить к вон тому роутеру можем, и это будет компактно, просто и эффективно.
А вон тот переросток с питонами-электронами в фузе туда чисто технически не уместится и благодать не наступит. Да и фуз на файловых операциях проц грузит мама не горюй, естественно, от паттернов доступа очень зависит.
| |
|
|
|
|
1.31, Аноним (31), 03:06, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> даёт возможность экономить как дисковую, так и оперативную память.
Зато проц нагнёт, нормальная такая экономия ресурсов.
| |
1.44, EuPhobos (ok), 07:04, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Отличия сводятся к обеспечению в Composefs эффективного совместного хранения содержимого нескольких примонтированных дисковых образов
Т.е. эта экономия не про "место на жёстком диске", а только про оперативку?
> Подобная модель обеспечивает дедупликацию и позволяет фактически хранить только одну копию одинаковых файлов
Если одинаковые файлы изначально идут с разных "примонтированных дисковых образов", о какой дедупликации тогда речь?
| |
|
2.48, Аноним (46), 07:39, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> одинаковые файлы изначально идут с разных "примонтированных дисковых образов", о какой
> дедупликации тогда речь?
Каждый образ в Composefs состоит из двух частей - сам образ только с метаданными и отдельное, общее для всех образов, хранилище данных, т.е. метаданные для всех образов разделены, а содержимое файлов свалено в общую кучу.
Монтируется как-то так
mount /путь/к/образу/с/метадаными -t composefs -o basedir=/путь/к/хранилищу/содержимого /mnt
| |
|
3.49, Аноним (50), 07:47, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
basedir нужно весь целиком держать с самого начала или можно пополнять по мере надобности?
| |
3.79, Аноним (52), 16:03, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> общее для всех образов, хранилище данных
и много есть образов с большими одинаковыми файлами на _одном_ физическом носителе?
| |
|
4.134, Аноним (112), 16:57, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Да. Например, в NixOS (оптимизируется хардлинками), да и в любой OSTree-like иерархии. Для дистрибутивов родом из 90х это, конечно же, не актуально.
| |
|
|
|
1.53, Аноним (55), 08:42, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Например, образы контейнеров содержат множество типовых системных файлов и в случае применения Composefs каждый из этих файлов будет совместно использован всеми примонтированными образами, без применения трюков, таких как проброс при помощи жёстких ссылок. При этом общие файлы не только хранятся в виде одной копии на диске, но и обходятся одной записью в страничном кэше, что даёт возможность экономить как дисковую, так и оперативную память.
Вспоминая про "безопасность" контейнеров, очень быстро найдутся умельцы которые с обновлением своего супер-мега контейнера подсунут в basedir либы с бекдорами, которые подтянутся другими контейнерами и вот вам готовая дырень.
| |
|
2.57, Аноним (-), 09:17, 29/11/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
> с обновлением своего супер-мега контейнера подсунут в basedir либы с бекдорами, которые подтянутся другими контейнерами
Как они потянутся, если у них будет свой собственный уникальный хеш, который не используется другими контейнерами?
| |
|
1.74, какая разница (?), 14:09, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Зачем? Вы ext4 надёжней сделайте.
Есть терабайтный диск с ext4, которая стала raw. Testdisk не нашел даже загрузочной записи, dmde и rlinux тоже ничего не нашли.
Отключал через безопасное отключение.
Теперь диск, отработавший всего 1022 часа, отправится в мусор, а вы так и будете клепать новые файловые системы..
| |
|
2.89, . (?), 18:01, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Теперь диск, отработавший всего 1022 часа, отправится в мусор
Ядро 5.19.* ? Если нет, то кто производитель диска?
| |
|
|
4.126, анон (?), 15:35, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
ссзб кмк, wd пихают хлам как диски для видеонаблюдения (маленьким шрифтом подписано что для холодного хранения), а железо там обычная блюшка с другой прошивкой. Надо брать ынтерпрайз диски.
| |
|
|
2.94, _kp (ok), 19:43, 29/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Да явно диск плохой. Я практически не пользуюсь безопасными отключениями ext4, и ничего страшного не происходит же. А компов у меня... много всяких.
| |
|
3.118, какая разница (?), 07:05, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Точно! Диск виноват. Только под windows и с ntfs диск работал без проблем, а в linux и с ext4 через раз определялся.
Но виноват диск, конечно..
| |
|
4.120, _kp (ok), 13:07, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Только под windows и с ntfs диск работал без проблем, а в linux и с ext4 через раз определялся.
Говорили мне не выноси мусор на ночь, примета плохая. Не послушал. Теперь и войны и санкции.
Ну, совпадение же.
Вот если бы у Вас, или у кого то то же самое массово с ССД повторялось, то об проблеме давно бы знали.
А пока подобное не подтверждается, и SSD с ext4 работают хорошо.
Да и упомянутый ресурс мизерный для любого использования, даже для дешевого SSD.
Остается только думать на брак.
| |
|
|
6.156, Аноним (-), 01:09, 03/12/2022 [^] [^^] [^^^] [ответить] | +/– | Он поди был видным представителем черепичных, как большинство современных винчей... большой текст свёрнут, показать | |
|
7.158, какая разница (?), 06:52, 03/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Он поди был видным представителем черепичных
WD Purple никогда не были с записью SMR, подробнее здесь
https://u.to/5CJ4HA
> отступить от партишн тэйбла немного чтобы оставить его в покое гражданин не догадался
NTFS это не требует и все работает
> ext4 никогда и не делали с прицелом на надежность
Из версии в версию постоянные улучшения в ядре по файловым системам, а как ломается - "это вы сами"..
| |
|
8.160, Аноним (-), 04:17, 04/12/2022 [^] [^^] [^^^] [ответить] | +/– | Забавный зверек Если бы не было написано CMR я бы подумал что ОНО именно черепи... большой текст свёрнут, показать | |
|
|
|
|
|
|
2.107, Admino (ok), 20:48, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ext4 тут причём, если диск сдох? Ты можешь доказать, что ext4 убила диск? Ждём твои сенсационные заявления в багтрекере ядра.
| |
2.111, Некто (??), 02:54, 30/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты криворучка. Ехт4 вполне тупая фс, которую можно вручную без драйвера разобрать, не говоря уже о photorec. Ещё у неё суперблок бекапится в разных частях диска. Зная где, можно примонтировать с бекапом.
| |
|
3.119, какая разница (?), 07:56, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
Диск не определяется в этих ваших "супер программах" типа photorec и testdisk! Как узнать где этот суперблок?
Ты лучше бы читать научился..
| |
|
2.121, Аноним (121), 13:57, 30/11/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
>Теперь диск, отработавший всего 1022 часа, отправится в мусор
Т.е., в основе проблема аппаратная? Тогда вопросы к произодителю диска.
| |
|
3.125, какая разница (?), 15:32, 30/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Диск отработавший 1022 часа через "безопасное отключение" стал raw вместо ext4 и теперь программами testdisk и dmde не находится даже суперблок, не говоря уж о резервном загрузчике..
| |
|
4.162, Аноним (-), 04:31, 04/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Диск отработавший 1022 часа через "безопасное отключение" стал raw вместо ext4 и
> теперь программами testdisk и dmde не находится даже суперблок, не говоря
> уж о резервном загрузчике..
Так на диске то что в результате? Таблица разделов есть? Какие-то правдоподобные данные остались? Если б вы NTFS сказали - окей, для него MS не так давно признавал такой факап, требующий определенных условий, их дожали после того как у юзеров сыпучка стала массово случаться. Но в линухе вот именно такой грабли не припоминается. Там откровенная сыпучка разве что у вон тех энтерпрайзников бездумно кладущие кеши на SSD, а когда тот протирается и продалбывает несколько крупных блоков - ну, ок, это превышает допущения большинства ФС и там это еще можно понять.
| |
|
5.164, какая разница (?), 08:34, 04/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> MS не так давно признавал такой факап, требующий определенных условий
Ссылка на источник тоже имеется?
> откровенная сыпучка разве что у вон тех энтерпрайзников бездумно кладущие кеши на SSD
WD никогда не выпускала SSD под маркой Purple. Пометь уже там в своей методичке..
| |
|
|
|
2.149, Аноним (-), 18:52, 01/12/2022 [^] [^^] [^^^] [ответить] | +/– | И запретите производить сыпучие диски, да И как тебе ext4, интересно, виноват в... большой текст свёрнут, показать | |
|
|
4.157, Аноним (-), 01:11, 03/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> WD не изобрела ещё SSD под маркой Purple..
Увы, сообщения нельзя редактировать, я про Purple позже нашел. Оно, вроде, черепица, так что идея почему оно могло слететь - похожая. Неудачный GC в области с партишном - и гудбай партишн.
> Это все, что нужно знать о местных экспертах..
Ну вы то покажете мастеркласс?
| |
|
5.159, какая разница (?), 06:57, 03/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Оно, вроде, черепица
Все ответы здесь https://u.to/5CJ4HA
> Ну вы то покажете мастеркласс?
Ну если вы не знаете, что WD никогда не выпускала SSD под маркой Purple и что WD Purple не выпускались с записью SMR, то это говорит, что вы не очень-то и разбираетесь - все на предположениях..
| |
|
6.163, Аноним (-), 04:35, 04/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
Теоретически, оттуда следует что это обычный диск с 4К секторами. Не очень понятно как и почему он партишн потерял, или что под "raw диском" имелось в виду?
> то это говорит, что вы не очень-то и разбираетесь - все на предположениях..
WD понаплодили линеек, да. А то было похоже на "крупноблочный облом". Но видимо не оно. В природе много странной ерунды, однако я уверен что слет партишна не является нормальным состоянием дел и EXT4 в этом не замечен. Как и вообще в внезапных харакири без причин. Если б вы это про NTFS сказали - там MS удалось вычислить в определенном случае, после начала массовых осыпонов. Но вон то является чем-то довольно нетипичным. И больше всего похоже на кривую работу железа.
| |
|
|
|
|
|
1.75, Пахом (?), 14:18, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Файловые системы в век SSD не нужны! SSD вполне себе может работать по принципу RAM.
| |
|
2.77, Аноним (52), 15:59, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Программы в век компьютеров не нужны! Компьютеры вполне себе могут работать по принципу ЦПУ.
| |
2.95, _kp (ok), 19:50, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
А без файловой системы Вы файлы то куда деваете?
А cо стиранием страницами и ограниченным ресурсом SSD может работать по принципу RAM весьма недолго, для избежания чего и нужны оптимизированные для SSD файловые системы.
| |
|
3.102, Пахом (?), 20:34, 29/11/2022 [^] [^^] [^^^] [ответить]
| +5 +/– |
Речь не про твоё старьё на SATA интерфейсе. Речь про нормальный человеческий NVMe.
| |
3.122, Аноним (121), 14:00, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
>А без файловой системы Вы файлы то куда деваете?
Раз SSD в качестве RAM, то в RAM создаётся рамдиск :)
| |
|
4.124, Пахом (?), 15:29, 30/11/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Не стыдно сидеть на компьютерном форуме и не знать как компьютер работает с памятью? Наверное все твои знания сводятся к командам git и npm.
| |
|
5.144, Аноним (144), 15:13, 01/12/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
А тебе лень глаза вверх на несколько постов поднять, чтоб сообразить, на какую заяву был ответ?
| |
|
4.127, _kp (ok), 16:04, 30/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>А без файловой системы Вы файлы то куда деваете?
> Раз SSD в качестве RAM, то в RAM создаётся рамдиск :)
Рамдиск тоже требует созданния на нём какой нибудь файловой системы.
И требует файловой системы везде, и на Linux, Windows, и на микроконтроллере, и даже на древнем ZX Spectrum.
Иначе останется блочным устройством для RAW операций :)
| |
|
|
2.150, Аноним (-), 18:56, 01/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Файловые системы в век SSD не нужны! SSD вполне себе может работать
> по принципу RAM.
А отсылать в конкретный файл как предлагается? Прямо по физическому/логическому адресу? Даешь hexspeak в массы! :)
| |
|
1.88, zog (??), 17:32, 29/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Объясните олдскульщику, зачем нужна файловая система, которая постоянно считает хеши? Она ведь будет тормозить, а в случае коллизии, гарантии от которой нет никакой, накроется тазом.
| |
|
2.91, qetuo (?), 18:05, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Она не считает хеши. Вернее, считает, но в основном использует готовые хеши из индекса. При этом она иммутабельная, так что пересчитывать ничего не нужно.
| |
|
3.93, Аноним (52), 19:09, 29/11/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> пересчитывать ничего не нужно
обновил мету в фильме - ой... оказывается, надо.
| |
|
4.113, Аноним (112), 03:43, 30/11/2022 [^] [^^] [^^^] [ответить]
| +/– |
> для монтирования образов в режиме только для чтения
> обновил мету в фильме
Новость не читай, сразу коммент пиши! Эксперды опеннета в своём обычном амплуа.
| |
|
|
2.96, _kp (ok), 19:52, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Для Flatpak, чтоб все данные в одну гигантскую кучу намешать.
| |
2.103, Аноним (-), 20:35, 29/11/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Она не постоянно их считает. Почитайте про принцип contrnt-adressable, в этом подходе мы заранее знаем что хотим, и запрашиваем вот именно это самое, окончательным идентификатором является хэш контента. Ну то-есть abcd.so -> (имя файла) a1b2c3....ef -> данные.
А то что кто-то там сто лет назад посчитал хэш(данные) и разложил его в файло с именем a1b2c3....ef потому что хэш такой, не обязывает его пересчитывать постоянно.
| |
2.133, Брат Анон (ok), 16:33, 30/11/2022 [^] [^^] [^^^] [ответить]
| +4 +/– |
Объясняю школьному одскульщику: ФС в режиме "только для чтения" не имеет изменяющихся частей. Хэш посчитали за тебя и даже не на твоём компьютере. Твои затраты минимальны. А выигрышь по занимаемому месту -- может оказаться от десятков процентов до кратных величин. ИМХО, не плохая прибавка к пенсии.
| |
|
3.141, Jxtym (?), 10:27, 01/12/2022 [^] [^^] [^^^] [ответить]
| –2 +/– |
Только вот сделана эта фс специально под fs-verify который будет хэши считать постоянно.
| |
|
4.167, Брат Анон (ok), 13:34, 05/12/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Только вот сделана эта фс специально под fs-verify который будет хэши считать
> постоянно.
Для чего хэши считать постоянно? Ещё раз: эта файловая система монтируется в режиме "только для чтения".
| |
|
5.169, Jxtym (?), 13:25, 06/12/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Только вот сделана эта фс специально под fs-verify который будет хэши считать
>> постоянно.
> Для чего хэши считать постоянно? Ещё раз: эта файловая система монтируется в
> режиме "только для чтения".
Для валидации данных очевидно. Все данные на оригинальной фс остаются в режиме записи.
Посмотрев на авторов становится очевидно что composefs скрестят с ostree хранилищем и получат подписанные образы на базе произвольного стора, которые можно будет встроить в secureboot цепочку(тут валидация и становится актуальной). Всё это актуально для silverblue подобных дистров.
| |
|
|
|
|
1.135, Аномин (?), 17:09, 30/11/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Flatpak критиковали за прожерливость диска, вот решение. И мне нравятся контейнеры, когда приложение не "размазывается" по всей системе и можно ограничить доступ, к сети, каталогам, дискам и тд.
Тот же Steam по этим соображениям лучше ставить в контейнер, чтобы игры не шарились где непоподя. У меня 2 стима, один из пакетов, второй во flatpak, там устанавливаю все подряд, ибо встроенные зловреды в игры вполне реальная вещь.
| |
|
2.142, Аноним (142), 14:23, 01/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
Проблема всяких паков не только в том, что место транжирится, но и в том что либы не обновляются.
| |
|
1.143, Аноним (142), 14:24, 01/12/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Круто. Давно пора. И с торрентами скрестить чтобы публично-доступные файлы было можно искать и качать по хэшу.
| |
|
2.151, Аноним (-), 18:58, 01/12/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Круто. Давно пора. И с торрентами скрестить чтобы публично-доступные файлы было можно
> искать и качать по хэшу.
Это eMule/aMule называлось и вот именно публиковало файло из дир по вот именно их хэшу, при том все кто с одинаковыми файлами автоматически находились :)
| |
|
|