The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews (??), 26-Май-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


102. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от birdie (ok), 27-Май-23, 11:52 
> etx4 - дерьмо

Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.

Более надёжной ФС в Линукс нет и не было.

Самый большой косяк - не умеет делать дефрагментацию свободного места, но с приходом SSD проблема перестала быть актуальной.

Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

105. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  –2 +/
Сообщение от DEF (?), 27-Май-23, 11:58 
>Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.

И чо? У одного только Фейсбука, btrfs юзается в хвост и в гриву на более миллиона серверов.

>Более надёжной ФС в Линукс нет и не было.

Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори.

>Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux.

Укатайка...

Ответить | Правка | Наверх | Cообщить модератору

114. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от birdie (ok), 27-Май-23, 12:39 
> Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори.

Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum.

Проблема не настолько серьёзная, чтобы говорить, что без этого ФС не ФС.

Я бы назвал data checksum nice to have фичей, но никак не crucial/essential.

Ответить | Правка | Наверх | Cообщить модератору

124. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +2 +/
Сообщение от DEF (?), 27-Май-23, 13:45 
>Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum.

Это не решения, а днищенские костыли. Гарантия целостности данных должна обеспечиваться на уровне ФС.

Ответить | Правка | Наверх | Cообщить модератору

126. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от birdie (ok), 27-Май-23, 13:58 
> Это не решения, а днищенские костыли.

Кто это решил? Я использую файлы с checksums более 20 лет. Проблем не было.

Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет? FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS). Приехали?

Я скажу ещё более страшную вешь - checksumming без recovery бесполезен буквально полностью. Всё, отдыхайте. А вот тут решений на уровне FS я не знаю вообще. Есть PAR2, но это бесконечный геморрой, который я заменил на RAR.

> должна обеспечиваться на уровне ФС

Кто кому должен? Почему должен?

Я сейчас скажу, что вы мне должны $1M, потому что так "правильно". Всё? Приехали?

Не надо свои хотелки превращать в status quo.

Ответить | Правка | Наверх | Cообщить модератору

201. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +2 +/
Сообщение от пох. (?), 28-Май-23, 00:20 
> Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам.
> Чем вам это поможет?

копий данных на современных fs может быть, внезапно, не одна. И даже носителей тоже может быть не один.

> FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS).

когда кажется - помогает креститься. zfs (как и любая другая с контролем целостности) ничего не выдаст, вернет ошибку чтения, если не имеет второй копии. И ты хотя бы узнаешь что файл поврежден (возможно копии нет у fs, а ты был умный и у тебя она есть где-то еще).
Если копия есть и валидна - молча вернется правильный блок, а битый при scrub будет перезаписан, без необходимости тебе лично участвовать в этом процессе.

Раз ты даже этого не знаешь - чего стоит твоя "экспертиза"?

Ответить | Правка | Наверх | Cообщить модератору

219. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  –3 +/
Сообщение от Sw00p aka Jerom (?), 28-Май-23, 10:34 
>копий данных на современных fs может быть, внезапно, не одна.

И какой копии доверять? Как доказать целостность? Где гарантии, что копии целые? Человек до сих пор не придумал этого механизма.

Ответить | Правка | Наверх | Cообщить модератору

280. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Прохожий (??), 29-Май-23, 11:01 
Тебе ж написали:контрольные суммы.
Ответить | Правка | Наверх | Cообщить модератору

282. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Sw00p aka Jerom (?), 29-Май-23, 11:36 
> Тебе ж написали:контрольные суммы.

а где храним эти контрольные суммы? и в каком количестве?

Ответить | Правка | Наверх | Cообщить модератору

400. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (400), 03-Июн-23, 19:38 
> а где храним эти контрольные суммы? и в каком количестве?

Ну вот в файлухе например можно, если это не блочный а "файловый" дизайн был. В количестве копий блока разумеется - если это нечто типа RAID1. А что, чексуммы мало места vs блок занимают, оверхеда не так уж много, ценой очень скромного оверхеда знаем какая копия верная и возможности (авто)рекавери сильно возрастают. Для штук типа RAID5 парити для блоков чексум можно и не хранить по математическим причинам, для блоков данных ессно чексумы надо.

Ответить | Правка | Наверх | Cообщить модератору

404. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Sw00p aka Jerom (?), 03-Июн-23, 21:26 
> знаем какая копия верная

откуда знаем? как понять чек-сумма битая или блок данных? разве не на том же устройстве они хранятся? кто дает гарантии "небитости" чек-сумм?


Ответить | Правка | Наверх | Cообщить модератору

411. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (411), 04-Июн-23, 01:15 
> откуда знаем? как понять чек-сумма битая или блок данных?

ИМХО пофиг: если не совпадает -> проблемная копия, просто берем из другой. И какая разница чексум в копии порушился или сам блок? Если у нас исправная копия есть, мы как раз и отрекаверим и блок и его чексум.

Эта логика на имеющихся у меня текучках и сыпучках работает изумительно, круто разворачивая теорвер в совсем другую сторону. Теперь даже на 1 неидеальном девайсе я проигрываю не "когда бэд попал под что-то важное" а "когда бэды совпали так что накрыло обе копии". И выиграть в такой джекпот при относительно редких сбоях и относительно большом числе секторов не очень реально за обозримое время. ИМХО так теорвер намного прикольнее ощущается. А всего лишь критерии проигрыша немного пересмотрели.

> разве не на том же устройстве они хранятся?

Вот как раз и пофиг, чексумы отъехали или блок, отрекаверить из исправной версии и дело с концом.

> кто дает гарантии "небитости" чек-сумм?

Стопроцентные конечно только страховой полис. Но если у вас глючное железо, на фс с чексумами это как раз очень хорошо видно когда расчитаное при записи не сходится с расчитаным при чтении, так что идут матюки фс в логи - и мы знаем что железо гунявое. У меня так целая мини коллекция глюкастиков образовалась, там и флехи, и карточки, и ссд, и мамка и проц и рама и даже шнурки сата :). Шнурки кстати в смарте видно но это ж надо явно лезть туда, а тут вот готовые матюки в логах...

Ответить | Правка | Наверх | Cообщить модератору

202. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  –1 +/
Сообщение от DEF (?), 28-Май-23, 00:52 
>Кто это решил?

Это решили логика и здравый смысл.
>Я использую файлы с checksums более 20 лет. Проблем не было.

Никого не интересует твой опыт использования костылей.

>Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет?

Я запущу scrub. Если у меня зеркальный RAID, то Btrfs автоматически восстановит поврежденные данные и метаданные из уцелевшей копии. Если у меня сингл, то ФС как минимум сообщит мне, какие блоки поврежденны и на каких файлах. И я как минимум не допущу попадания битых файлов в новый бэкап и восстановлю их из старого бэкапа.

>Кто кому должен? Почему должен?

За целостность данных в реляционной БД отвечает именно БД, а не какие-то костыли за пределами БД. Точно также и с ФС. ФС для этого и создана, чтобы обеспечивать целостность данных. Это ее прямая зона ответственности.

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

223. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  –2 +/
Сообщение от birdie (ok), 28-Май-23, 12:56 
*ля, стыдно всё это читать.

Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums?

Или вы реально думаете, что домашние пользователи все побежали делать RAID и хранить копии данных в трёх географических разделённых местах?

У вас г*вно в голове, уважаемый - вы считаете априори, что

1) Все данные - это безумно важно!
2) Нужно убиться потратить денег, чтобы их не потерять даже в случае атомной зимы!

Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно.

Вы так бы и начали: "вот я работаю там и там, у нас такие критерии, нам только ZFS подходит".

Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING".

*ля. Ржу. Корона не жмёт?

Ответить | Правка | Наверх | Cообщить модератору

237. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от dasd (?), 28-Май-23, 17:34 
>Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums?

Начните уже думать, а не только троллить.
RAID защищает немножко от другого.
Куча копий данных - как выбрать верную? (Битовые ошибки - существуют)

Ответить | Правка | Наверх | Cообщить модератору

317. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от DEF (?), 30-Май-23, 17:10 
Мда. С тобой все ясно. Таблетки не забывай принимать вовремя, которые тебе назначил твой лечащий психиатр.
Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

401. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 03-Июн-23, 19:53 
> Если у вас есть RAID, куча копий данных, да на кой хрен
> вам вообще checksums?

А откуда мы знаем которая из копий на райде правильная когда на отличия налетели? Ну вот для этого чексумы и надо :). Кроме того чексумы проверяют работу железа end to end.

И если сбойное железо не отлавливать - оно и кучу копий может прекрасно загадить. Счет и верификация чексум выступают неплохой такой "канарейкой" сильно демаскирующей это все.

> Или вы реально думаете, что домашние пользователи все побежали делать RAID и
> хранить копии данных в трёх географических разделённых местах?

Если нет, они тогда бегут вооон туда, в лабу по дата рекавери и облегчаются на круглые суммы, после чего те кто поумнее обычно начинают делать бэкапы, уважать райды и вообще.

> 1) Все данные - это безумно важно!
> 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае
> атомной зимы!

А прелесть btrfs как раз в том что можно заметно улучшить свойства, используя то что есть, без безумных затрат или энтерпрайзных требований. А так по жизни вовремя детектить глюки железа это очень полезная идея. Одно дело если я глюкастик в фоне заменю и другое если у меня рабочий проект развалится или глюкастик взбрыкнет в самый ответственный момент, как это по законам мерфи и случается.

> Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно.

В btrfs это все может быть в виде когда этим можно даже простому юзеру пользоваться и не париться. Схему DUP на ноутбучном диске вкатить - 1 команда в командлайне. Зато рандомный бэд раз в эн лет под метаданными прекрасно пережило, парировало и вместо ВНЕЗАПНОЙ переустановки оси в мыле я занимаюсь моими проектиками. Ну а с вашими технологиями я бы вместо этого полдня пыхтел с наруливанием операционки. Что занимает сильно больше времени чем 1 команду btrfs было скроить.

> Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING".

А таки реально - гно. Я встречал довольно много юзеров у которых ВНЕЗАПНО разлетелась файлуха до немоунтабельного состояния (чаще всего NTFS). Резко и без предупреждения. Еще вчера они свои проекты делали. Сегодня винда в бсод улетает при попытке диск прицепитьб и вообще ни 1 файла не достать. А оказывается у них там оперативочка битая, процик глюкавенький, шнурок гнилой, но они узнали об этом только когда наконец какие-то метаданные фатально накрылись и драйвер ушел в страну вечной охоты. Это кстати баг драйвера, но если вам ваш проект было надо, бодаться с сапортом майков на эту тему вам вовсе не с руки. Как и выяснять почему chkdisk это не чинит. Врядли у вас есть полгода с сапортом майков переписываться, поэтому зачастую народ юзает альтернативные планы. Так я и узнал что это бывает. Потому что внезапно, я могу и с таким подарком справиться.

> *ля. Ржу. Корона не жмёт?

Пока вы тупили, штуки типа btrfs сделали продвинутые фичи довольно доступными и ненапряжными. Представляете, в конце XIX века поездку на авто приходилось готовить почти как экспедицию. А в XXI веке мы просто плюхаемся в кресло и поехали. Хотя действо то же самое. И да т.к. отсутствие чексум ведет к резким развалам без предупреждения, это реально хреново. Так что имхо у того субъкта есть пойнт. Но да, я тоже испорчен btrfs. Зато, вот, мою коллекцию глюкастиков пополнил. Несколько флех, sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый проц... нормальненько так :) можно вам из этого комп свинтить, а вы и не заметите так сразу :P.

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

417. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от onanim (?), 04-Июн-23, 08:45 
> Несколько флех,
> sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый
> проц...

мне китайский переходник SATA-USB наделал в ссд кучу Uncorrectable ошибок и даже один Reallocated, и дико тормозило чтение-запись. я думал, что диск помирает, пока не попробовал другой переходник.

Ответить | Правка | Наверх | Cообщить модератору

191. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +1 +/
Сообщение от Kuromi (ok), 27-Май-23, 23:07 
Именно поэтому Гугль потихоньку переводит Андроид на f2fs для RW (хотя тут неточно) и EROFS для RO (вот тут уже решение принято).
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

327. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (324), 31-Май-23, 01:59 
> Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.

Математика не нужна. Миллионы школьников не могут ошибаться.

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру