Чем хорош LVM

> И возможности снапшотов там покруче, чем в zfs

Что, прямо-таки любой можно взять и клонировать, к примеру?

любое изменение в фс можно автоматически сохранять как снапшот

Вернее, оно сохраняется как checkpoint. Который ФС вполне может взять и удалить при нехватке места.. А для того, чтобы не удалила - его нужно как snapshot пометить, путем выполнения соответствующей команды. Ну или просто с ее помощью создать снимок в нужный момент, что, на мой взгляд, гораздо удобнее, чем рыскать по автоматическим checkpoint'ам в поисках того, который тебе нужен.

Главное, что дистрибостроители это стали понимать. Hal выпилили — и хорошо.

Только не вздумай гуглить на что HAL заменили. Иначе инфаркт гарантирован.

Я не подведу =) 2 диска в RAID 1 по 1Tb, отдельные разделы /, /tmp, /var, /home

А потом через годик порноторренты перестанут влазить на этот терабайт, ты сходишь в магазин за ещё парой (двух)терабайтников и... тут то и начнётся самое интересное =).

А еще LVM умеет снапшоты, мгновенные.

rollback позволяет? Как это нет? Тогда зачем он такой красивый нужен?

Ещё понравилось:

Если устройство-«снапшот» полностью заполняется, оно автоматически деактивируется. В этом случае «снапшот» не может более использоваться, потому крайне важно выделять достаточное пространство для него.

...тут и сел старик.

Запись данных на том, с которого сделан снимок, очень сильно замедлена по сравнению с обычной работой!

Тогда зачем он такой красивый нужен?

Чтобы сделать дамп файловой системы и после этого избавиться от снапшота.

Вот сидишь ты с терабайтным дампом файловой системы и думаешь: а не лучше ли было tar/gzip файлов сделать.

Вот сидишь ты с терабайтным дампом файловой системы и думаешь: а не лучше ли было tar/gzip файлов сделать.

Мозг включи. Я тебе не про dd, а про dump. Иначе бы звучал термин раздел/том/whatever, но не «файловая система».

Да понял я.

вот хоть ты и троллишь иногда жестко, а здесь я с тобой, пожалуй соглашусь. Реализация снапшотов в LVM пригодна только для бэкапов, и то не всегда. Реализация же их в ZFS(btrfs пока еще сыра, nilfs ИМХО не умеет rollback) находится на совершенно другом качественном уровне. И пусть в меня кинут тапок за разжигание срача, но такую реализацию(заметь, не обязательно ZFS) снапшотов я бы хотел видеть в Linux.

> Большинство проблем от непродуманного планирования

Ну, считай, что я запланировал принципиальную возможность неограниченного увеличения ёмкости дискового массива и использую для этого LVM. И когда (скоро) я куплю диск на террабайт, то он органично вольётся к двум другим. А ты будешь плодить /mnt/video-disk, /mnt/new-video-disk и /mnt/yet-another-video-disk.

объяснил бы хоть.

А потом через годик порноторренты перестанут влазить на этот терабайт, ты сходишь в магазин за ещё парой (двух)терабайтников и... тут то и начнётся самое интересное =).

Не злоупотребляю =)

> rollback позволяет

Позволяет. man dm-merge. Хватит уже постить заведомо ложную информацию.

В любом случае, в линуксе есть более правильная ФС со снапшотами — nilfs2. А монстры ZFS и btrfs сдохнут очень быстро.

Ну ты процетировал же фразу Билла Гейтса, а он отошел от Майкрософта же... Ммм... Ну не знаю как объяснить =)

Для нищебродов и сделан ZFS.
Для остальных снапы делаются средствами SAN

rollback позволяет

Позволяет. man dm-merge. Хватит уже постить заведомо ложную информацию.

Первый раз слышу. Нигде не могу найти man dm-merge. Может ссылочку запостишь почитать, чтобы не постить в будущем заведомо ложную информацию?

Для нищебродов и сделан ZFS.

Именно. ZFS создан для объединения и менеджмента пулов дешёвых устройств хранения. А то, что эти устройства по отдельности вылетают через один, призваны компенсировать избыточность внутри устройств верхнего уровня и СКВОЗНАЯ_ЦЕЛОСТНОСТЬ_ДАННЫХ.

>Позволяет. man dm-merge.

Эта левая фиговина уже год как загнулась. Сейчас оно делается через lvconvert --merge.

>Для нищебродов и сделан ZFS.

По-моему, основная цель создания ZFS - показать, как НЕ НАДО писать файловые системы. Напихали в одну кучу несколько различных подсистем, получили никакую гибкость и большие тормоза.

Отличный урок будущим поколениям кодеров.

> Эта левая фиговина уже год как загнулась. Сейчас оно делается через lvconvert --merge.

Не суть, важно, что поддержка слияния есть.

> По-моему, основная цель создания ZFS - показать, как НЕ НАДО писать файловые системы

Именно! Полностью согласен.

Эта левая фиговина уже год как загнулась. Сейчас оно делается через lvconvert --merge.

Не суть, важно, что поддержка слияния есть.

Нету такого.

???

Может есть вменяемые ссылки на продвинутый man lvconvert?

> По-моему, основная цель создания ZFS - показать, как НЕ НАДО писать файловые системы.

Цель создания ZFS определена вполне чётко: сократить вычисления и обработку по пересылке данных с уровня на уровень программных абстракций физических устройств.

Напихали в одну кучу несколько различных подсистем, получили никакую гибкость и большие тормоза.

Ложь.

Получил скорость ~43МБ/с при записи файлов на ZFSv15 RAID-Z из дешёвеньких/тормозных ноутбучных винтов с 5400rpm и 8МБ кэша каждый. При этом десктоп и настольные приложения не замерзали на время копирования, курсор даже не чуял, что в фоне что-то копируется большое, как в Linux. ЧЯДНТ?

У меня linux не тормозит при копировании, ЧЯДНТ?

По-моему, основная цель создания ZFS - показать, как НЕ НАДО писать файловые системы. Напихали в одну кучу несколько различных подсистем, получили никакую гибкость

Вот тут и тут приведены интересные циферки по поводу количества строк кода ядра в ZFS и линуксовых ФС и LVM. Например, количество строк в XFS+LVM в 2.6.34 в сумме ~120000 строк, а ZFS - ~102000. Поддержка крипто в ZFS еще тыщ 5-6 строк добавит, и все равно будет меньше.. Как так, а?

С разницей в гибкости и функциональности сам разберешься?

и большие тормоза.

Это ты пхороникса начитался?

Отличный урок будущим поколениям кодеров.

Вот я тоже думаю, что хороший урок.. Только мы о разном :-)

>Цель создания ZFS определена вполне чётко: сократить вычисления и обработку по пересылке данных с уровня на уровень программных абстракций физических устройств.

В таком случае, она благополучно провалена. Внутри ZFS жестко разделена на независимые уровни, как и дисковый стек линукса. Другое дело, что без ковыряния кода, извне эти уровни недоступны -> нет гибкости.

А тормоза обусловлены уже кривыми ручками разработчиков.

Получил скорость ~43МБ/с при записи файлов на ZFSv15 RAID-Z из дешёвеньких/тормозных ноутбучных винтов с 5400rpm и 8МБ кэша каждый.

И этим еще гордятся... facepalm.png

При этом десктоп и настольные приложения не замерзали на время копирования, курсор даже не чуял, что в фоне что-то копируется большое, как в Linux.

И в линуксе не замерзают, не вижу поводов для распальцовки.

>Вот тут и тут приведены интересные циферки по поводу количества строк кода ядра в ZFS и линуксовых ФС и LVM. Например, количество строк в XFS+LVM в 2.6.34 в сумме ~120000 строк, а ZFS - ~102000. Поддержка крипто в ZFS еще тыщ 5-6 строк добавит, и все равно будет меньше.. Как так, а?

Что сказать-то хотел?

С разницей в гибкости и функциональности сам разберешься?

А что там разбираться? Вывод очевиден: ZFS - к позорному столбу.

Это ты пхороникса начитался?

И не только.

>Поддержка крипто в ZFS еще тыщ 5-6 строк добавит, и все равно будет меньше..

Боюсь, никто никогда не узнает, сколько строчек добавит поддержка шифрования в ZFS... кроме кодеров оракла.

Уж оракел-то найдет способ не открывать сорцы новых версий ZFS.

>Получил скорость ~43МБ/с при записи файлов на ZFSv15 RAID-Z из дешёвеньких/тормозных ноутбучных винтов с 5400rpm и 8МБ кэша каждый.

А теперь сравни это со скоростью ufs2 поверх gvinum или graid5 :-)

Feel the difference, как говорится.

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

Сэр я гляжу знаком с тем, что там внутри у ZFS.. Круто!

Другое дело, что без ковыряния кода, извне эти уровни недоступны -> нет гибкости.

Это ты так думаешь. Пример привести или сам догадаешься?

> Что сказать-то хотел?

Что твое утверждение насчет примера «как не надо писать ФС» необосновано, мягко говоря.

А что там разбираться? Вывод очевиден: ZFS - к позорному столбу.

Конечно же, сэр может обосновать свою точку зрения..

И не только.

Например?

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

Ну-ну... Продолжай бояться дальше:

http://src.opensolaris.org/source/xref/zfs-crypto/gate/usr/src/uts/common/fs/...

Уж оракел-то найдет способ не открывать сорцы новых версий ZFS.

Поживем - увидим..

А теперь сравни это со скоростью ufs2 поверх gvinum или graid5 :-)

Сравнивал ZFS mirror и GEOM_MIRROR с UFS2 на одних и тех же дисках. GRAID5 не знаю, что такое. Запись на UFS2 в зеркале GEOM приблизительно на 10% быстрее, чем на ZFS пул.

>Сэр я гляжу знаком с тем, что там внутри у ZFS.. Круто!

Совсем необязательно быть мега-хакером, чтобы понимать разницу между уровнями SPA/DMU/ZVOL и ZPL.

Это ты так думаешь. Пример привести или сам догадаешься?

Пример: хранение БД на блочном устройстве без ФС, снятие бэкапа через снапшот. В LVM возможно, потому что там уровень менеджера томов отделен от ФС. В ZFS - нет.

Что твое утверждение насчет примера «как не надо писать ФС» необосновано, мягко говоря.

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

http://src.opensolaris.org/source/xref/zfs-crypto/gate/usr/src/uts/common/fs/...

Luast updated: 27-Sep-2010

Опасения перешли в уверенность...

>GRAID5 не знаю, что такое

Это экспериментальная реализация _нормального_ RAID5 для FreeBSD. Не прошло и десяти лет...

Пока в основном дереве отсутствует, тестируется.

Запись на UFS2 в зеркале GEOM приблизительно на 10% быстрее, чем на ZFS пул.

Ты что-то не так делаешь. Там обычно не меньше 50% выходит, при нескольких потоках (что лучше отражает ситуацию на нагруженных серверах) вообще в два-три раза.

Ты что-то не так делаешь.

Всё я правильно делаю. И, да, GMIRROR заводился на первых, а ZFS mirror пул собран был на вторых от начала диска разделах.

> Пример: хранение БД на блочном устройстве без ФС, снятие бэкапа через снапшот. В LVM возможно, потому что там уровень менеджера томов отделен от ФС. В ZFS - нет.

А, ты про юзерленд... Я вообще люстру имел ввиду.

Дык тут вон зажравшиеся соискатели утверждают, что снимки надо делать в SAN'е, а не какими-то LVM'ами.

Что твое утверждение насчет примера «как не надо писать ФС» необосновано, мягко говоря.

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

А голову включить? Стили оформления кода - принципиально не отличаются. Строчек тоже не полтора десятка. Уже кое-какие выводы можно делать. А если еще функциональность сравнить.. Но ты для себя уже все выводы сделал, поэтому переубеждать я тебя не буду. Пустое это..

> Ты что-то не так делаешь. Там обычно не меньше 50% выходит, при нескольких потоках (что лучше отражает ситуацию на нагруженных серверах) вообще в два-три раза.

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

> Всё я правильно делаю.

Как то не вяжется с тем, что ниже:

И, да, GMIRROR заводился на первых, а ZFS mirror пул собран был на вторых от начала диска разделах.

Сравнивать - так уж на одних и тех же разделах, а еще лучше на дисках целиком.

Сравнивать - так уж на одних и тех же разделах, а еще лучше на дисках целиком.

Извини, не ставил целью что-то кому-то продемонстрировать. Просто делал для интереса для себя, хотелось оценить «тормоза».

> Извини, не ставил целью что-то кому-то продемонстрировать. Просто делал для интереса для себя, хотелось оценить «тормоза».

Да я не против. Просто было бы неплохо о такой «несущественной» детали упоминать, когда результатами другим приводишь.

LVM нужен если у вас мультимедийный контент

LVM не нужен и в этом случае

Специально для тебя потрудился: snapshot-merge target. Причитающиеся мне $5 перечисли, пожалуйста, в фонд похорон FreeBSD.

Специально для тебя потрудился...

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

Просто было бы неплохо о такой «несущественной» детали упоминать, когда результатами другим приводишь.

В общем-то, против моего пыта на натурном испытании ты не привёл ничего, кроме что-то где-то услышал про тормоза ZFS. Тогда о чём ещё можно говорить?

Вполне себе удобная вещь, особенно тот вариант, что а AIX.
В продакшене используется достаточно активно, так как даёт необходимую гибкость и «отвязку» от физических разделов, что особенно актуально для тех же SAN.

>>Другое дело, что без ковыряния кода, извне эти уровни недоступны -> нет гибкости.

хехе, еще один клоун.

зы попкорном уже затарился? =)

>>Пример: хранение БД на блочном устройстве без ФС, снятие бэкапа через снапшот. В LVM возможно, потому что там уровень менеджера томов отделен от ФС. В ZFS - нет.

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

ну вот как-раз ту погрешность и имеем ;)

>>снапы делаются средствами SAN

а чем делаешь? свичами? или hba удобнее?