Первый стабильный выпуск ZFSonLinux

Чем и как ты мерял производительность?

dd.

А размеры изменений для снапшотов по преженему ограничены и требуют выделения пространства или оно автоматически научилось наконец расти?

http://www.kernelcrash.com/blog/linux-lvm-in-2012/2012/08/08/

Задолбали боевые хомячки ZFS.

задолбали боевые хомячки LVM

http://www.kernelcrash.com/blog/linux-lvm-in-2012/2012/08/08/

только это всё-равно убогая концепция - задавать размер под снапшот, а по ссылке соответственно костыль, который ещё и 'delayed detection'. ну и как всегда - оно вроде как бы и работает, но только вроде и как бы:

Regarding the auto-extend functionality of thin pools, well I could not get it to work (so far I’ve tried Redhat 6.3 and Fedora 17). The details of how to use it are in the comments of /etc/lvm/lvm.conf on most distros, for whatever reasons, it never auto-extends for me.

короче костыль костылём погоняет в этом вашем lvm.

Regarding the auto-extend functionality of thin pools, well I could not get it to work (so far I’ve tried Redhat 6.3 and Fedora 17)

1. Мне как бы пофиг на мнение неосиляторов ...

2. потому что я специально проверил работу авторасширяющихся снапшотов

3. И поскольку они работают, см. пункт 1.

dd.

Ясно, досвидос.

One thing I immediately noticed when I tried this out myself is that it is still a ‘delayed’ detection. ie. if your snapshot fills up too quickly and hits 100% before the autoextend detector kicks in then you’re stuffed.

Читай сам, что присылаешь.

dd.

Ясно, досвидос.

Ты когда-то перепуталь ключики if и of и теперь у тебя его упоминание вызывает ненависть?

if your snapshot fills up too quickly and hits 100% before the autoextend detector kicks in then you’re stuffed.

Отдай под снапшот столько достаточно, чтобы он не заполнился за время между срабатываниями чекера. Хотя, если у тебя нелады с математикой, то тебе этот совет не поможет.

Ты когда-то перепуталь ключики if и of и теперь у тебя его упоминание вызывает ненависть?

При замерах dd слишком много косяков всплывает.

Отдай под снапшот столько достаточно, чтобы он не заполнился за время между срабатываниями чекера. Хотя, если у тебя нелады с математикой, то тебе этот совет не поможет.

Почему я вапще должен думать о размерах снапшотов? Пусть о занимаемом месте мониторинг думает, а не я.

1. Мне как бы пофиг на мнение неосиляторов ...

ты то неосилятор тот ещё, чего уж там, но за lvm вроде не докопаться, так что ладно, поверим.

ну и тебе уже не один я привожу довод, что «defective» это как раз таки lvm, со своим выделением раздела под снэпы.

Пусть о занимаемом месте мониторинг думает, а не я.

ССЗБ. Только руководству не говори - не поймёт.

ССЗБ. Только руководству не говори - не поймёт.

Не, если тебе нравится постоянно руками что-то доправлять и фиксить - как тебе угодно. Мне больше нравятся решения «поставил и забыл».

Ты когда-то перепуталь ключики if и of и теперь у тебя его упоминание вызывает ненависть?

Ну и моделью какой же именно реальной промышленной нагрузки является dd?

Ну и моделью какой же именно реальной промышленной нагрузки является dd?

дак у него и жаба на серверах только и делает, что стартует да останавливается, на каждое обращение.

Например, моделью сброса кэша

Ок, так и запишем - в неведомой конторе no-dashi сброс какого-то кэша является важной продуктивной нагрузкой, что, по всей видимости, автоматически делает dd универсальным инструментом измерения производительности для всех

Например, моделью сброса кэша

ага, и dd if=/dev/random у тебя моделирует random io...

Если когда-нибудь твой IQ превысит IQ типичного сисадмина, возможно тебе доведётся столкнуться с БД с buffer cache в гигабайт этак хотя бы 50 и выше, ты поймешь, почему dd является достаточно точным инструментом тестирования.

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

жаль только твой не достигнет даже этого и ты так и не поймёшь разницу между random и sequential io.