The OpenNET Project / Index page

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



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

Оглавление

Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..., opennews (??), 10-Янв-20, (0) [смотреть все] +1

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


189. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 10-Янв-20, 22:29 
> ext4 без выкрутасов?

ну да - восстанавливаешься с бэкапа после очередной "silent corruption", никаких выкрутасов.

Нет, если тебе васян-сайтик или там десктоп уже почти совсем окончательно полностью готовый но не - вполне сойдет, а если надо хранилку лично тебе дорогих хотя бы 4-10 терабайтиков - то доверять их что голой ext4, что, тем более, ext4 с прослойками в виде md и lvm - надо быть смелым и нестяжателем (по крайней мере, цифрового добра).

Хотя гуанокластеры бегут к тебе на помощь (педобир.jpg)

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

212. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (-), 11-Янв-20, 07:30 
>доверять их что голой ext4

Слушай ты видно тролль, я сомневаюсь что ты лнуксоид. Эта файловая система давно уже журналируема.

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

230. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Аноним (229), 11-Янв-20, 08:49 
> давно уже журналируема.

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

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

234. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (273), 11-Янв-20, 09:12 
есть T10/DIF который вроде эту проблему решать должен..
Ответить | Правка | Наверх | Cообщить модератору

248. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от пох. (?), 11-Янв-20, 11:50 
>> давно уже журналируема.
> Она, конечно, журналируема...
> - Но полный журнал медленный как трактор.

вы не понимаете - оно вообще не об этом.

Оно - механизм, позволяющий потерять последнюю запись, если все остальное осталось в идеальном виде. (да, да, сюрприз - потерять) Ни от каких silent corruptions оно не защищает в принципе, и придумано не для этого, в 2002м году - попробуйте, если не опоздали родиться, вспомнить - и догадайтесь, зачем на самом деле.

К сожалению, год у нас нынче предвоен...зачеркнуто, 2020й.

> - Чексумы данных нет.

она на не-redundant-fs (zfs в том числе) не поможет ни при каких обстоятельствах, только усугубит ситуацию - пара байтиков в середине терабайтного ролика о нелегком труде конее6а "выйду в поле с конем" может вообще остаться незамеченной зрителем, сосредоточенном на сюжете. А в ващем случае приведет к превращению _всего_ файла в тыкву.


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

309. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (307), 12-Янв-20, 08:25 
> Оно - механизм, позволяющий потерять последнюю запись, если все остальное осталось в
> идеальном виде.

Ну так транзакционная семантика - она вообще о том что либо мы доводим операцию до конца, либо теряем. А так что оно подвисло в промежуточном состоянии и ни туда, ни сюда - это самый паршивый из всех вариантов.

Ну вот декодировался у тебя жыпег до середины. Дальше либа сказала decode error, потому что с точки зрения разборки деревьев Хаффмана получился какой-то бред. И чего дальше с ним делать?!

> (да, да, сюрприз - потерять) Ни от каких silent corruptions оно не защищает
> в принципе, и придумано не для этого,

Ну спасибо, Кэп.

> остаться незамеченной зрителем, сосредоточенном на сюжете. А в ващем случае приведет
> к превращению _всего_ файла в тыкву.

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

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

323. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 12-Янв-20, 16:08 
> Ну так транзакционная семантика - она вообще о том что либо мы
> доводим операцию до конца, либо теряем. А так что оно подвисло

ну да, и причем бы тут bitrot? Оно вообще не о том.

> в промежуточном состоянии и ни туда, ни сюда - это самый
> паршивый из всех вариантов.

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

С бинарными файлами - то же самое. Часто можно спасти если не все, то многое.

> Ну вот декодировался у тебя жыпег до середины. Дальше либа сказала decode
> error, потому что с точки зрения разборки деревьев Хаффмана получился какой-то
> бред. И чего дальше с ним делать?!

искать что-то похожее на начало блока, и пытаться стартовать оттуда. Потому что если это фотография поверхности марса, к примеру - второй можно не дождаться. Надо пытаться сохранить те обрывки, что есть.

Ну и, разумеется, стараться использовать форматы, менее критичные к выпадениями фрагментов.

> Ну спасибо, Кэп.

как видите, многим адептам неочевидно.

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

возможно. В большинстве случаев.

А ext2 journal таки придуман в ~2002м совершенно для другого. И представлял собой неизящный костыль. Оставим адептам для домашнего задания выяснить и разобраться, какой именно действительно актуальной тогда проблемы пытались так избежать.

Причем по факту проблем на ровном месте прибавилось, их одолевали следующие пять лет. К 2010му уже можно бы было и пользоваться, но уже было не особенно надо.

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

348. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 13-Янв-20, 11:11 
> ну да, и причем бы тут bitrot? Оно вообще не о том.

Иногда у людей виснет комп, слетает питание, жмется ресет,  сдергивается без размонтирования. Это не bit rot а неудачно срубленная запись.

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

Это если плейнтекст был и записалось что-то похожее на плейнтекст. А если это офисный документ например - упс!

> С бинарными файлами - то же самое. Часто можно спасти если не все, то многое.

Иногда - можно. Но это уже отдельное приключение на тему data recovery. И лучше на него не налетать.

> искать что-то похожее на начало блока, и пытаться стартовать оттуда.

Иногда получается. Как у тех чудных форумов на замурованном сервере, где нижняя половина картинки интереснее марсианских пейзажей.

> Потому что если это фотография поверхности марса, к примеру - второй можно не
> дождаться. Надо пытаться сохранить те обрывки, что есть.

Те кто фотографии с марса шлет - поумнее будут, там многоуровневый FEC и половину сигнала можно продолбать, все-равно декодируется. И даже так можешь почитать как Phil Karn брал под управление полудохлый космический аппарат. Но на каждую фотку котят такого спеца не вызовешь.

> Ну и, разумеется, стараться использовать форматы, менее критичные к выпадениями фрагментов.

Большинство форматов на этой планете сделаны ну вообще совсем без учета этого фактора. Кроме разве что сильно некоторых архивных форматов.

> возможно. В большинстве случаев.

Щас. Другое дело что все-же должно не повезти и это не часто.

> какой именно действительно актуальной тогда проблемы пытались так избежать.

А оно мне надо в исторических костяшках копаться? Я знаю зачем журналирование на самом деле должно быть - мне и хватит. А археология костылестроения - отдельная наука.

> Причем по факту проблем на ровном месте прибавилось, их одолевали следующие пять
> лет. К 2010му уже можно бы было и пользоваться, но уже было не особенно надо.

Ну так и ZFS небось не за 5 минут накодили. Файлухи вообще как-то требуют времени на стабилизацию и отлов corner cases, которые зачастую вообще не предусмотрели господа разработчики.

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

231. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (229), 11-Янв-20, 08:50 
> Слушай ты видно тролль, я сомневаюсь что ты лнуксоид.

Он изначально санкосолярщик какой-то, чтоли. А потом его жизнь и корпорация Оракл поимели.

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

243. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 11-Янв-20, 11:33 
>>доверять их что голой ext4
> Слушай ты видно тролль, я сомневаюсь что ты лнуксоид.

если ты под "линуксоидами", как и я , собственно, понимаешь истово верующих - то разумеется я к ним не отношусь.

> Эта файловая система давно уже журналируема.

блестящая демонстрация, спасибо. То есть священные слова выучены, а что они означают - верующему знать не надо, надо просто долбить мантру три тысячи раз на дню, и все исполнится ("на шестой день - облысел, на седьмой - посинел, на девятый - прыщами весь покрылся")

Журналируема, ага. К счастью, хотя бы этот механизм превращения fs в веселенькую вермишель (после череды образцово-показательных факапов - стал) более-менее защищен от срабатывания (но это неточно, это я верю разработчику на слово, причем с тех пор десять раз могли все снова испортить ;-)  

Как жаль что он не имеет ни малейшего отношения к защите от описываемого явления, и предназначен - вам необязательно знать, для чего - просто долбите мантру чаще.

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

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

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




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

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