The OpenNET Project / Index page

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



"В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Для слежения за появлением новых сообщений в нити, нажмите "Проследить за развитием треда".
. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/
Сообщение от Аноним (-), 24-Ноя-23, 22:26 
> ты перепутал со своим любимым lvm.

Я как раз терпеть его не могу, считая отвратительным легаси. CoW файлухи это эстетичнее делают, сделав все нужные метаданные нативной частью дизайна. Так сильно лучше работает чем те убогие костыли. Конечно если сильно хочется, можно и запорожец, на орбиту, но...

> У CoW никакой дельты нет. Новые записи ВСЕГДА "дельта".

Спасибо, Капитан Очевидность! Это не отменяет того факта что де факто есть "core set" блоков на которые N референсов, и эн "дельт" которые разъехались относительно оного и были записаны cow в сторонку. Может и сложнее быть, упрощенная картинка позволяет чайникам понять суть проблематики и особенности управления таким звездолетом. CoW диски виртуалок по примерно таким же идеям работают и сталкиваются с похожими проблемами. Хотя они будучи блочными сущностями скорее ближе к LVM, но общая идея остается. Просто для продвинутого cow оно становится сложнее и многофакторнее. Можно такие вот ансамбли миров отращивать, с разными таймлайнами. Совпадающие часты могут (но не обязаны) храниться вместе. Отличающиеся по отдельности.

> Разница только в том что если старые зафиксированы в снапшоте - они
> не будут со временем перезаписаны чем-то другим.

Вот ты кэп то! :). Прости, я в курсе как устроен гипердрайв и как им продвинуто рулить.

> У меня снапшоты никак не влияют на скорость фс.

Они сами по себе - в разумных пределах - и не обязаны. А с чего им? Сам по себе лишний референс на энный экстент вообще жить никак не мешает. В zfs наверное чуть больше оверхеда с их блоками переменного размера, но оно бы не было cow если бы не могло с этим жить.

А вот если не понимать те аспекты управления такими гипердрайвами - можно забить себе пространство и налететь на фрагментацию. В вобщем то любом дизайне. Даже дисками виртуалок так можно доиграться. Факт в том что должен быть некий маневровый резерв кужа cow'ать можно.

> Местный дypaчок скорее всего в очередной раз забил фс выше 90% но виноваты конечно
> снапшоты.

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

Btrfs'ники то на этот случай могут потрепыхаться дефрагером. Хоть и с "особенностями".

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

Оглавление
В OpenZFS выявлена ошибка, которая может привести к повреждению файлов, opennews, 23-Ноя-23, 11:30  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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