The OpenNET Project / Index page

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



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

Оглавление

В OpenZFS выявлена ошибка, которая может привести к повреждению файлов, opennews (??), 23-Ноя-23, (0) [смотреть все]

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


51. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от fidoman (ok), 23-Ноя-23, 13:39 
Интересно, этим "разработчикам" не приходила в их светлые головы мысль, что если я копирую файл, то мне нужна КОПИЯ файла, а если я хочу чтобы эти два файла ссылались на одни и те же блоки, то я бы включил -o dedup?
Ответить | Правка | Наверх | Cообщить модератору

134. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от 1 (??), 23-Ноя-23, 17:12 
Ну и чем КОПИЯ (авторская раскладка сохранена) отличается от копии с автодупликацией ? Тебе на пользовательском уровне не всё равно
Если тебе нужна прям КОПИЯ КОПИЯ - копируй в другое облачко.
Ответить | Правка | Наверх | Cообщить модератору

167. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (165), 23-Ноя-23, 19:43 
> Ну и чем КОПИЯ (авторская раскладка сохранена) отличается от копии с автодупликацией ?

Тем, что при повреждении носителя вероятность потерять все копии значительно ниже.

> Тебе на пользовательском уровне не всё равно

У пользователей Винда и Мак, на которых ZFS, очевидно, нет. При чём тут пользовательский уровень к серверным файловым системам?

> Если тебе нужна прям КОПИЯ КОПИЯ - копируй в другое облачко.

Я и есть «облачко». Что теперь делать прикажешь?

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

172. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (172), 23-Ноя-23, 20:11 
>У пользователей Винда и Мак

Где Вы берёте таких пользователей?
На более разумных не хватает ФОТ?

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

203. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +1 +/
Сообщение от Аноним (165), 24-Ноя-23, 01:01 
У 1% элитарных войнов-линуксойдов денег нет. Приходится с быдло99% возиться. А что сделать, элитность юзеров в тарелку не положишь.
Ответить | Правка | Наверх | Cообщить модератору

171. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от fidoman (ok), 23-Ноя-23, 20:06 
1) меньше i/o, потому что при записи не надо аллочить блоки и обновлять счётчики ссылок.
2) уверенность, что при перезаписи этого файла (если это образ виртуалки к примеру) неожиданно не кончится место - то есть информация о том что места не хватает вылезет в момент когда человек сидит за консолью и копирует, а не в 23:00 31.12

Ах да, простите, наверное я всё же не ответил на ваш вопрос. С ПОЛЬЗОВАТЕЛЬСКОЙ точки зрения, конечно же, всё равно.

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

235. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от 1 (??), 24-Ноя-23, 09:47 
> 1) меньше i/o, потому что при записи не надо аллочить блоки и обновлять счётчики ссылок.

Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? Я что-то пропустил и завезли новую математику ?
> 2) уверенность, что при перезаписи этого файла (если это образ виртуалки к примеру) неожиданно не кончится место

Это вот ближе к теме ... Правда не при "перезаписи", а при перемещении ... на другой датастор, например. Всегда есть вероятность, что при дедупликации и сжатии места не хватит при реаллокейте ... Но что-то я мало видел желающих проводить работы в 23:00 30.12.

Тут же отвечу из поста повыше, по поводу порчи места на носителе... Там между носителем и FS ещё пара уровней имеется.

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

257. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от fidoman (ok), 24-Ноя-23, 12:50 
> Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? Я что-то пропустил и завезли новую математику ?

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

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

326. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 26-Ноя-23, 01:35 
>> Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ?
>> Я что-то пропустил и завезли новую математику ?
> Не завезли, но есть такая вещь как планирование. Копирование запускаем в период
> наименьшей нагрузки, затем в пиковых режимах избыточной нагрузки уже не будет.

Ну во первых оно займет место. И это стоит денег. Во вторых - IO таки грузит. И долго. Если результат этой операции интересовал (а иначе она зачем вообще?) - все надолго встает на якорь.

> Собственно удобно было бы если бы оно после предоставления копии с
> рефами уже в фоне разносило бы блоки,

CoW так и работает по задумке - как блоки расходятся, так оно и. А если не расходятся - зачем на них место и IO тратить?

> но этого вроде как нет. Даже если сделать сложную схему с преаллоком, что читаем из
> тех блоков, а новое пишем вот сюда - всё равно дополнительные расходы на то чтоб отметить,

Показать метаданными 2 раза на 1 регион само по себе вообще не обязано быть чем-то тяжелым.

> что блок из оригинала уже не нужен (уменьшить рефкаунт) и отметить что читать
> уже из нового (дополнительная запись в метадату).

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

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

197. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 00:42 
> Интересно, этим "разработчикам" не приходила в их светлые головы мысль, что если
> я копирую файл, то мне нужна КОПИЯ файла,

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

Что актуально для деплоя десятка виртуалок из шаблона например. Они изначально одинаковые, отличаться могут маргинально, и в результате места сожрут в разы меньше. Без жора сотен рамы на дедуп и нагрузки на проц - виртуалки и сами по себе это покушать не против, еще ФС это давать.

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

231. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от fidoman (ok), 24-Ноя-23, 09:19 
> явно запросил

Откуда инфа про "явно"? В обсуждении пишут что оно автоматом стало делаться при копировании в свежих coreutils.

> Что актуально для деплоя десятка виртуалок из шаблона например

сделай zfs clone шаблона и запускай
Не так гибко в том плане что нельзя шаблон грохнуть, но по крайней фича старая и больше шансов, что работает нормально, и не включается сама там где её не просят.

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

286. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от пох. (?), 24-Ноя-23, 19:32 
> Откуда инфа про "явно"? В обсуждении пишут что оно автоматом стало делаться при копировании в
> свежих coreutils.

кому интересны ваши гнупроблемы? Предъявляйте претензии авторам корявоутилсов, зачем они делают у вас то о чем их никто не просил.

> сделай zfs clone шаблона и запускай

Как жаль что zfs не умеет clone отдельных файлов (нет)

Песок плохая замена овсу. Отсутствие у cow-based fs рефлинков - очень странная проблема. Как бы намекающая нам что в разработке все плохо (потому что попытки ее решить тянутся уже лет пять)

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

290. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 20:19 
>> явно запросил
> Откуда инфа про "явно"?

С точки зрения файлухи - софт должен явно ioctl вхреначить на это дело, сигняля что они хотят вот именно клон файла.

> В обсуждении пишут что оно автоматом стало делаться
> при копировании в свежих coreutils.

Возможно. Это в конечном итоге вопрос дефолтов энных программ. Лично мне например такие дефолты удобны - если я хочу копию файла как именно нечто занимающее +эн места, я это обычно на ДРУГОЙ ФС хочу. Как раз из соображений сохранности. Потому что rm -rf или dd в накопитель например убьет обе копии одинаково эффективно. И занимать 2 раза на 1 ФС/накопителе место - ну - знаете, если это реально надо было - то RAID1 и DUP это делают лучше. Еще и с чексумами. Можно сразу понимать кто побился, чинить это в фоне, и без педального привода чтобы закатывать солнце вручную.

>> Что актуально для деплоя десятка виртуалок из шаблона например
> сделай zfs clone шаблона и запускай
> Не так гибко в том плане что нельзя шаблон грохнуть, но по
> крайней фича старая и больше шансов, что работает нормально, и не
> включается сама там где её не просят.

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

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

308. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от fidoman (ok), 25-Ноя-23, 11:19 
> из соображений сохранности

Не о сохранности речь, если бы речь была о ней, то, допустим, сделать копию файлика в папочку save перед тем как вносить какие-то изменения - тут reflink был бы как раз уместен, эдакий снепшот 1 файла, разрастающийся только по мере того, как делается cow.
Нет, вопрос если я делаю копию допустим файла БД или образа диска и хочу чтобы это была другая БД/виртуалка - тут уже однозначно надо, чтобы все блоки были сразу закопированы и у каждого файла они были свои - и дальнейшая работа с ними происходила без дрoчилова метадаты.

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

322. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 26-Ноя-23, 00:52 
>> из соображений сохранности
> Не о сохранности речь, если бы речь была о ней,

Если это не интересовало, то идея делать вот именно полную честную копию, когда возможно рефлинк - довольно странная. Это сожрет больше места, потратит больше времени, а профит - в чем?

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

Ну да. И на уровень менеджмента ЭТО как раз и не отсвечивает, будучи 100% прозрачной абстракцией для решения вот именно вопроса создания локальных независимых якобы-копий. Которые можно, вот, независимо эволюционировать и проч.

Например так удобно поднимать пачку однотипных виртуалок для какого-то эксперимента из шаблона. Если известно что виртуалки будут не особо активные по записям, и в целом похожие, но мелкие отличия типа легкой кастомизации конфигурации - вот - совершенно прозрачно прокатят, хотя "core set" блоков в лучшем случае останется один на всю толпу, а десяток экземпляров нарезается из шаблона без натужного копирования дофига гигз. При этом мы врядли хотели чтобы сам факт создания такой штуки - как-то отсвечивал в менеджменте именно ФС. Какие-то ключевые моменты - при определенных условиях - еще может быть. Но за сам факт создания такой штуки? Ну вот нет.

> Нет, вопрос если я делаю копию допустим файла БД или образа диска
> и хочу чтобы это была другая БД/виртуалка - тут уже однозначно
> надо, чтобы все блоки были сразу закопированы и у каждого файла
> они были свои - и дальнейшая работа с ними происходила без

Да? А я то делая дата рекавери как раз оценил что вычитав вооон ту немеряную чушку с эн-терабайтного подубитого диска, можно на ней экспериментировать, например, не догонит ли fsck это до моунтабельного вида, сделав как раз рефлинкнутую копию. И как раз та иллюзия с одной стороны делает "копирование" моментальным (копировать несколько терабайт в принципе очень не прикольно) - и экономит дофигища места. А прозрачная абстракция поддерживает иллюзию что это разные файлы. И вот fsck лихо чинит "копию" диска-в-файле. Большая часть блоков конечно же shared останется, а в сторонку запишутся только изменения от fsck. А дальше - если не понравился результат, стер этого рефлинка да еще раз попробовал! А оригинал - вот, как раз, лежит себе, его никто не трогает. И в целом так соотношения намного круче. И по нужде в месте на стораже куда это складируется, и по времени на то чтобы переиграть вариант результат которого не понравился. Есть большая разница между копированием нескольких терабайтов и рефлинком на них. Второе завершается за какие-то секунды.

Если это было про диски виртуалок и проч - вот там уже смотреть надо. Для малоактивных виртуалок, таки, рефлинк может быть вариантом. Для активных по дисковому IO - ну вот там вы CoW врядли хотели уже. А таки пачка виртуалок таким манером лихо подымается, и как вариант в палитру - очень даже. Но вот там уже стоит понимать что и зачем делаем.

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

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

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




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

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