The OpenNET Project / Index page

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



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

Оглавление

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

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


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ообщить модератору

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

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




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

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