The OpenNET Project / Index page

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



"Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux " –1 +/
Сообщение от csdoc (ok), 22-Апр-15, 14:47 
> А чем экстент фундаментально отличается от блока переменного размера,
> с очень большим максимальным размером? У zfs трабл в этом самом размере,
> что обрекает их ворочать немало метаданных даже в случае когда можно
> было бы просто вкатить все одним регионом, с компактным и быстрым
> описанием. Наверное поэтому оно так и выглядит в бенчах vs btrfs.

CoW и экстенты плохо совместимы между собой.

У ZFS - более простой и надежный код в этом месте,
ценой некоторого уменьшения производительности.

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

Если надо "ехать" - тогда ZFS выглядит более привлекательно,
Если нужны "шашечки" - тогда более привлекательно выглядит BTRFS.

> А можно вот как-то на уровне ФС сжульничать с чем-то типа снапшотов,
> freeze/thaw и прочая, чтобы избавиться от постоянной записи в бэкапируемый файл.
> Но если это без явного подыгрыша со стороны БД, вы все-равно получите базу
> и журналы в состоянии "как было". Т.е. запросто на середине какой-то транзакции
> в процессе. Это не консистентная копия БД. Если такой бэкап БД подсунуть,
> БД должна сделать аварийное восстановление с реплеем журнала и откатом/докатом
> транзакций, как после краха системы.

Правильно. После чего база данных переходит в консистентное состяние.

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

В чем именно "граблеопасность" ?

> Такому "бэкапу" в общем случае надо будет как
> минимум реплей журнала как после жесткого краха.

База данных это сделает самостоятельно.

=========================================

>>>>> У CoW всегда растут метаданные при перезаписях.
>>>> Не всегда.
>>> Простите? Чтобы старое состояние не разрушилось, надо делать новый выносок. Как вы
>>> себе представляете создание этого выноска без метаданных, которые описывают что это
>>> вообще такое и к чему это относится?

=========================================

>> Например, если нет снапшотов - метаданные файловой системы просто меняются но не растут.
> А, вы кажется начинаете догадываться почему в btrfs сделали CoW отключаемым

Нет, я говорю о том, что ваше утверждение
"У CoW всегда растут метаданные при перезаписях"
ошибочно и не соответствует действительности.

> Судя по активному развитию Unbreakable Linux - оракл оказался
> как-то совсем не против барыжить и линухом на х86.

Нет никакого "активного развития Unbreakable Linux" - оракл просто ворует результаты
работы Red Hat и пытаются заработать, продавая техническую поддержку к чужому продукту.

> долговременные перспективы - в unbreakable linux

нет никакого "unbreakable linux", это на 100% маркетинг и обман.

> В линухе вон сколько народа систему пилит. А в соляре только сам оракл.
> Им это сильно надо? Мне как-то кажется что не очень, капиталисты - жадные.

Странно, почему ж тогда майкрософт не откроет исходники виндовса под лицензией GPL ?

> Архитектура у линукса далеко не лучшая.
> Но от операцоинки всем надо не супер-архитектуру.

ошибки в архитектуре очень дорого обходятся. например:
http://habrahabr.ru/post/53048/
http://habrahabr.ru/post/179333/

>> Причем, LVM Cache будет апдейтить мелкие-мелкие блоки
>> в метаданных, так что write amplification будет в полный рост.
> во первых для линукса есть несколько вариантов кэшей.

ладно, какой из этих вариантов лучше всего подходит для использования с BTRFS ?

из стабильных в RHEL есть всего один вариант, - это LVM Cache.

> Во вторых что там реально будет происходить и как это отмаппится в фактические
> erase/program - очень сложный вопрос, точно просчитать это вообще невозможно.
> Можно лишь грубо прикинуть на основе знаний как работает флэш и что ему удобно,
> но все-равно остается много неизвестных в уравнении и делать громкие заявления
> на песке - это так по сановски...

еще раз:

LVM Cache хранит на SSD как данные кеша, так и метаданные.
метаданные - это мелкие блоки информации.

L2ARC хранит на SSD только данные, а метаданные хранятся в памяти.

еще не очевидно какой из двух вариантов кешей будет меньше
изнашивать SSD и давать большую скорость работы с кешем ?

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

Оглавление
Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux , opennews, 09-Апр-15, 21:25  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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