Представлен (https://groups.google.com/a/zfsonlinux.org/group/zfs-announc...) новый экспериментальный выпуск zfsonlinux 0.6.0-rc9 (http://zfsonlinux.org/), в рамках которого развивается модуль для ядра Linux с поддержкой ZFS. В новой версии исправлено множество ошибок и закрыт ряд ранее найденных и оформленных сообщений о проблемах в подсистемах SPL (Solaris Posix Layer) и ZFS (Zettabyte File System). Версия пула и FS в ZFS соответствует версиям в FreeBSD 9.0/8.3 и совместима с ними (можно переносить через zfs send/receive).
Стоит отметить, что уже сейчас данная реализация ZFS для Linux является весьма стабильной и используется энтузиастами даже на боевых системах. Модули с поддержкой ZFS недавно были включены в состав дистрибутивов Gentoo и Sabayon Linux.
Дополнительно можно упомянуть перевод (http://capitoshka.blogspot.com/2012/05/faq-zfs-on-linux.html) официального FAQ проекта ZFSonLinux, а также ряд заметок по настройке zfsonlinux в англоязычных блогах - "ZFS on Linux and pool replication (http://blog.rot13.org/2011/09/zfs-on-linux-and-pool-replicat...)" и "ZFS and DTrace running on Ubuntu Linux (http://liberumvir.com/2012/06/01/zfs-and-dtrace-running-on-u...)" (перевод (http://www.opennet.me/tips/2696_zfs_ubuntu_disk_raidz.shtml)).
URL: https://groups.google.com/a/zfsonlinux.org/group/zfs-announc...
Новость: http://www.opennet.me/opennews/art.shtml?num=34107
До btrfs оно не могло появиться?
btrfs уже готов?
так же как и сабж
> btrfs уже готов?По меркам "стабильности" и "скорости" ZFS, btrfs уже давно готов к промышленному применению. Вот только чудакам-разработчикам этих мерок маловато, они хотят еще лучше...
Они хотят
1) Оптимизировать по скорости
2) Реализовать кучу фич
3) Оттестировать по человечески
4) Сделать привычные всем утилиты типа fsck в полном объеме.Вроде бы все по уму. Можно ли пользоваться сейчас? Да, при желании - можно. Будет ли работать? Будет. Будут ли факапы? При обычных сценариях - врядли. Очевидные грабли? Полноценного отлаженного fsck в классическом виде - нет. Правда есть другие утили. Не во всех случаях скорость и оверхед оптимальны.
В общем если рассуждать теми же критериями что в *bsd - этим давно уже можно пользоваться. А если как в ext3/4 - тогда еще подождать.
> Будет ли работать? Будет. Будут ли факапы? При обычных сценариях - врядли.Именно! Сделал пару серверов (на одном 2 диска - mirror на ZFS), на втором - 3 диска - RAIDZ1.
Тестим работу, делаем crash-тесты - внезапное отключение питания (20 раз подряд при разных сценариях), "внезапно" отключаем по одному винту с последующем reset-ом....подключаем обратно, делаем online/scrub/clean....все работает. При обычных сценариях не убивается, как не пытался.
Ладно, идем дальше - вешаем сервисы (почту, прокси, сайты), даем рабочую нагрузку (от 100 до 500 пользователей).
Работаем несколько месяцев, периодически делаем бекапы через snapshot-ы (с отправкой через | gzip | ssh, etc...).
Ну не падает оно у меня :)
PS: С FreeBSD/ZFS было точно так же году в 2008-м вроде - как версия 13-я пула стала - так аналогичный сценарий тестирования и использования был. Где на одном винте, где на 2-х (mirror), где на множестве (raidz1) - нигде с тех пор не умерло - в сумме около 20-22 инсталляций. на разном железе, у разных клиентов.
PSS: Типовые сценарии у 95% админов - если не падает оно - значит это и есть production (и бекапы никто и никогда не отменял :) ).
Надо лучше стараться - тогда упадет =))
Что в этих сценариях даже файлы не провреждались и не терялись?
Чем эти Z рейды лучше обычных связок softraid+lvm+fs? Попроще настраиваются наверно. А по скорости и надежности?
Например, после отрывания и подключения обратно диска в райд восстановление зеркала идёт не с пустого диска, а только для изменений, прошедших с момента отрывания диска.Например, наличие снапшотов не требует ресурсов, кроме места на диске. Систему с lvm нельзя использовать с сотней снапшотов. zfs - можно.
zfs можно удобно реплицировать, пересылая на другой хост изменения, накопившиеся на фс за последнюю минуту, час, день.
Если у вас SAN, и один том видит более чем одна машина, то случайно вы не примонтируете ул на двух машинах, zfs не даст. Без zfs вам для этого понадобится настраивать clvm или lvm-cluster - те ещё звери, зачастую приносящие больше проблем, чем решают.
перейти на zfs после старых-добрых раздельных менеджеров томов, райдов и файловых систем - как пересесть с автомобиля 50х годов выпуска на автомобиль конца 90х.
А тем временем оракл предлагает бтр ынтырпрайзу уже сейчас.
Тама уже заработало fsck?
А в zfs?
Зыж
Тама не знаю, не пользуюсь.
У меня на генте - да.
> А в zfs?А разработчики ZFS не осилили fsck.
На FreeBSD 9.0 ZFS стресс-тест не прошла. Сценарий такой:Берем i386 (на старой железке, 1GB RAM - соответственно, не больше 500 на нужды ZFS). Поднимаем пул на raidz гиг на 500, включаем дедупликатор на содзданной ФС и льем туда гиг 200 бинарников (в моем случае, lvm-снимки с виртуалок). Результат = выбег словаря (БД хэшей) за границы памяти ядра с закономерным kernel panic'ом. Вытащить данные, не сменив конфигурацию железа, в такой ситуации вряд ли получится (я по крайней мере не придумал как).
Вывод: защиты от факапа не встроено, для продакшена не созрело. Для себя пока заюзал OpenIndiana с рядом подстраховок для подобных задач.
> На FreeBSD 9.0 ZFS стресс-тест не прошла. Сценарий такой:
> Берем i386 (на старой железке, 1GB RAM - соответственно, не
> больше 500 на нужды ZFS). Поднимаем пул на raidz гиг на
> 500, включаем дедупликатор на содзданной ФС и льем туда гиг 200
> бинарников (в моем случае, lvm-снимки с виртуалок). Результат = выбег словаря
> (БД хэшей) за границы памяти ядра с закономерным kernel panic'ом. Вытащить
> данные, не сменив конфигурацию железа, в такой ситуации вряд ли получится
> (я по крайней мере не придумал как).
> Вывод: защиты от факапа не встроено, для продакшена не созрело.
> Для себя пока заюзал OpenIndiana с рядом подстраховок для подобных задач.i386 и не предназначен для ZFS - сколько раз в этом убеждался....
Замените в тесте i386 на amd64 и памяти до 2 Гб. И попробуйте уронить......
У меня есть сервачок с ZFS на amd64 и 1 Гб ОЗУ - после минимально рекомендуемого тюнинга тоже ни разу не падал за 3,5 года.
>> На FreeBSD 9.0 ZFS стресс-тест не прошла. Сценарий такой:
>> Берем i386Рекомендации применяли: http://wiki.freebsd.org/ZFSTuningGuide ?
Попробуйте хотя бы эти:
vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"
> Рекомендации применяли: http://wiki.freebsd.org/ZFSTuningGuide ?
> Попробуйте хотя бы эти:
> vm.kmem_size="330M"
> vm.kmem_size_max="330M"
> vfs.zfs.arc_max="40M"
> vfs.zfs.vdev.cache.size="5M"Ну дык, с этого и начал. Предположительно, грабля где-то в этом районе:
http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/00844...
Во первых, btrfs кривое подделие, его придумал один человек, а потом приделывал фичи, которые по определению там быть не могут.
Во вторых, ZFS создала Sun. Лично у меня (и думаю не только у меня), больше доверия к Sun, ежели к какому-то Крису.
> Во вторых, ZFS создала Sun. Лично у меня (и думаю не только
> у меня), больше доверия к Sun, ежели к какому-то Крису.Хорошо, что в Сане софт пишу^H^Hсали не люди, а роботы-сгибальщики.
Плохо, что они теперь не с на^W^Wв Сане.
ZFS - не менее кривое поделие. И лично я (и не только я) не вижу причин доверять индусам из sun больше, чем ораклу.
Что же вам везде индусы-то видятся?
Один из создателей ZFS - Джефф Бонвик, написавший слябовый аллокатор (который потом был реализован и в Linux) в конце 80х =)
http://en.wikipedia.org/wiki/Jeff_Bonwick
Все бы замечательно, только вот за аллокацию блоками в как максимум мегабайт - можно отдельно обругать. Толи блоки-переростки, толи недо-экстенты. Не понятно что разработчики хотели таким дизайном сказать. Для чисто блочного аллокатора уже слишком навернуто и главный козырь в виде простоты идет лесом, а для экстентов как-то хиловат максимальный размер. Ни два, ни полтора какое-то. Ну и работает соответственно.
Ээээ, вы о чем?
Максимальный размер блока в ZFS - 128 Кб
Экстентов в ZFS нет.
> Максимальный размер блока в ZFS - 128 КбСпросите у ваших более компетентных коллег - они вам расскажут что с бубном можно и до мегабайта догнаться.
> Экстентов в ZFS нет.
Ну да. Блоки даже на мег - хиловато для экстентов. Но уже и простоты чисто-блочного деления с постоянным размером нет. Франкенштейн какой-то, при том нафиг оно именно вот такое вот - кто-то может вообще внятно обосновать?
>> Максимальный размер блока в ZFS - 128 Кб
> Спросите у ваших более компетентных коллег - они вам расскажут что с
> бубном можно и до мегабайта догнаться.
>> Экстентов в ZFS нет.
> Ну да. Блоки даже на мег - хиловато для экстентов. Но уже
> и простоты чисто-блочного деления с постоянным размером нет. Франкенштейн какой-то, при
> том нафиг оно именно вот такое вот - кто-то может вообще
> внятно обосновать?Оно работает, старик.
> Оно работает, старик.FAT16 тоже работает, мальчик.
> Оно работает, старик."Работает" - понятие относительное. БД с ненулевой нагрузкой на зфс класть нельзя в принципе.
Руки у тебя растут совсем из другого места. В принципе.
> Руки у тебя растут совсем из другого места. В принципе.А что, в ZFS есть какой-то аналог btrfs'овского nodatacow? Чтобы срубить CoW, который для БД как собаке пятая нога. Раз уж мы о пряморукости тут.
"Лично у меня (и думаю не только у меня), больше доверия к Sun, ежели к какому-то" Джеффу!
> ZFS - не менее кривое поделие. И лично я (и не толькоВам сетевым всезнайкам поди непонятна ни одна их этих ФС.
ZFS же запрещает использовать в линукс лицензия. Т е это будет незаконно, почти как пиратка. Не?
> ZFS же запрещает использовать в линукс лицензия. Т е это будет незаконно, почти как пиратка. Не?Дык этот сабж из FreeBSD портировали где BSD, а не из Solaris, где CDDL.
В FreeBSD код ZFS под CDDL, как впрочем и везде.
> ZFS же запрещает использовать в линукс лицензия.При желании можно и заворкэраундить, так что юридически - кое-как протиснется, с рядом оговорок и плясков с бубном. Но я думаю понятно что такое в майнлайн в жизни не попадет а потому внятных перспектив не имеет.
> ZFS же запрещает использовать в линукс лицензия. Т е это будет незаконно, почти как пиратка. Не?Не. В Linux внедрены проприетарные прошивки для контроллёров SAS, Wi-Fi, видео, различные закрытые прошивочные компоненты от производителей железок. Никто из программистов ядра Linux даже не задумываются о том или ином массиве байт, описанных в исходных текстах, пересылаемом ядром в железку и обратно. Просто это пересылается "как есть" без возможности детального анализа того, что эти байты из себя представляют, какой алгоритм работы в них реализуется.
ZFS распространяется под открытой лицензией CDDL, не препятствующей сосуществованию с ней совместно коду под любой другой лицензией. CDDL закрывает от перелицензирования конкретный файл, который изначально шёл под ней. Линуксоиды не могут дописать или пропатчить файл под CDDL, не оставив только исходную лицензию. Им обязательно нужно воткнуть GPLv2, но некуда, кроме собственных файлов (в ZFS нет кода под GPL). Поэтому здесь чисто идеологические проблемы несовместимости лицензий.
> Не. В Linux внедрены проприетарные прошивки для контроллёров SAS, Wi-Fi, видео,Расскажи плиз, а что делает по этому поводу твоя бздя? Я вижу 2 опции:
1) Все-таки вгрузить в железку прошивку и она заработает.
2) Показать фигу юзеру и объявить что увы, железка работать не будет.Кстати некоторые такие фирмвари переписали в открытом виде. Например, для AR9170 (юсбшный атерос), некоторых нвидий, была попытка для броадкома написать.
> различные закрытые прошивочные компоненты от производителей железок.
Ну и кто виноват что в железках не так уж редко свой сервисный проц попадается без своего набортного хранилища для прошивки? Ну задизайнили чипмейкеры свой чип вот так вот. Хост должен слать в них фирмваре чтоб оно работало. Ну неидеален мир, да. И чего предлагается?
> Никто из программистов ядра Linux даже не задумываются о том или ином
> массиве байт, описанных в исходных текстах, пересылаемом ядром в железку
> и обратно. Просто это пересылается "как есть" без возможности детального
> анализа того, что эти байты из себя представляют, какой алгоритм работы в них реализуется.И что забавно, твоя бзда будет перед той же дилеммой. Ты или посылаешь эти байты и железка работает. Или не посылаешь - и она не работает.
> Линуксоиды не могут дописать или пропатчить файл под CDDL,
...но поскольку они не побирушки и не пресмыкающиеся, они просто пошлют сани/оракл нафиг с таким подходом и зафигачат свой btrfs, с шахматами и поэтессами. В отличие от - у них достаточно сил чтобы не питаться подачками.
Запрещено распространение готовых бинарных сборок. Написать маленькую обертку под CDDL для возможности сборки и дать юзеру команду, которой это развернуть (собрать) - будет абсолютно легально. Именно это авторы порта в новости и сделали.
> ZFS - не менее кривое поделие.Да, конечно. Всезнающий-товарищ Аноним то уж точно знает как устроены и работают ФС, а в частности ZFS и btrfs.
> Во первых, btrfs кривоеВо первых, это надо бы обосновать.
Во вторых, надо бы обосновать что ZFS прямее.> подделие
В третьих, марш в школу.
> больше доверия к Sun
Sun сдох. Что есть доверие к трупу?
> Sun сдох. Что есть доверие к трупу?Это он так некрофилию называет.
> Во первых, это надо бы обосновать.http://habrahabr.ru/post/108629/
> Во вторых, надо бы обосновать что ZFS прямее.
А я и не говорил что ZFS прямее.
>> Во первых, это надо бы обосновать.
> http://habrahabr.ru/post/108629/Мнением д'Артаньяна, который даже рейзер4 в ядро пропихнуть не сумел, можно пренебречь.
>> Во первых, это надо бы обосновать.
> http://habrahabr.ru/post/108629/А, это шишкин и его клинические краевые случаи типа томов на 600 метров забитых до отказа мелочью? Бывает. Вот только для ZFS он что-то постеснялся так же :)
>> Во вторых, надо бы обосновать что ZFS прямее.
> А я и не говорил что ZFS прямее.Ну ой. А у шишкина вообще даже действующий макет файловой системы - очень схематичный и приблизительный. Но вы в вашем праве им пользоваться если считаете что оно лучше ZFS, BTRFS и прочих. Ориентированных на то чтобы работало в реальном мире, а не только являлось красивой теорией.
И да, не хочу ничего сказать, но времена жестких дисков на 600Мб давно закончились. Бывают отдельные спецслучаи, но там никто в здравом уме btrfs, zfs и прочие и не применяет.
> действующий макет файловой системы -
> очень схематичный и приблизительный.лично мне его идея про модульность самой файловой системы (и драйвера) очень импонирует, это даст очень большую гибкость
>> Во первых, btrfs кривое
> Во первых, это надо бы обосновать.установи и ... "хавай фан" ,) - это ппц
> Во вторых, надо бы обосновать что ZFS прямее.
вещь отличная, но дома масштабы не те чтобы заценить ...
> Sun сдох. Что есть доверие к трупу?
Это теперь Oracle, тот же самый кто делает твою btrfs ...
Так что да - марш в школу! :)
>установи и ... "хавай фан" ,) - это ппцугу.
отлично работает на ноуте с 500Гб винтом с декабря 2011.
компрессия, автофрагментация включены.
чё ещё? да, снэпшоты позволили безболезненно опробовать самые экзотические конфигурации ядра/де/глибц/гцц/..
>> Во первых, это надо бы обосновать.
> установи и ... "хавай фан" ,) - это ппцОфигенное обоснование.
>> Во вторых, надо бы обосновать что ZFS прямее.
> вещь отличная, но дома масштабы не те чтобы заценить ...Не, так не пойдет. Ты расскажи чем она лучше btrfs. В сравнении. Вот это - аргументы. А то что ты тут втираешь - маркетинговый булшит и личные предпочтения. Это ты можешь засунуть туда где не светит солнце: на техническом ресурсе полагается приводить технические аргументы.
>> Sun сдох. Что есть доверие к трупу?
> Это теперь Oracle, тот же самый кто делает твою btrfs ...Ваши данные устарели - Крис Мэйсон уже срулил из оракла. FAIL :)
> Так что да - марш в школу! :)
Не-не, не так! "Вылезайте уже из вашей криокамеры!"
К Ссану никакого доверия нет после того как они глупо слили некрософту, а как макнили то бахвалился...
Вообще-то с формальной стороны и то и то написала одна компания. Все написала Sun принадлежит Oracle-у.
> Вообще-то с формальной стороны и то и то написала одна компания. Все
> написала Sun принадлежит Oracle-у.Да нифига. ZFS был написан во времена Sun, а вот btrfs уже после.
> Да нифига. ZFS был написан во времена Sun, а вот btrfs уже после.Поэтому btrfsу можно доверять, а ZFS - нет.
странное проявление боязни выбора
такое ощущение что oracle слабо финансирует разработку btrfs
> такое ощущение что oracle слабо финансирует разработку btrfsНе очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше, так как не имеет некоторых анноящих косяков дизайна ZFS.
> бтр подходит гораздо лучше, так как не имеет некоторых анноящих косяков дизайна ZFSПруф?
> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
> так как не имеет некоторых анноящих косяков дизайна ZFS.Ваш btrfs это один сплошной косяк дизайна.
> Ваш btrfs это один сплошной косяк дизайна.Не больший чем ZFS. По крайней мере обратное надо бы обосновать.
> Ваш btrfs это один сплошной косяк дизайна.По сравнению с ZFS, бтр сдизайнен очень неплохо.
> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
> так как не имеет некоторых анноящих косяков дизайна ZFS.Любопытно прочитать подробнее, что за косяки, и чем анноящие. Можно ссылочку?
>> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
>> так как не имеет некоторых анноящих косяков дизайна ZFS.
> Любопытно прочитать подробнее, что за косяки, и чем анноящие. Можно ссылочку?Тормозной он на их базах. Впрочем не только на них. И да, сервак БД это не файлсерв, там сабой БД хорошо бы кеш отдать. Так что позволить ФС захавать 100500 гигз оперативы чтобы выправить ее тормоза немеряным буфером уже не получается. А вот ораклу такой расклад как-то не очень нравится. Наверное это и мотивировало их затеять ФС которая была бы лучше, в том числе и с их базами.
>>> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
>>> так как не имеет некоторых анноящих косяков дизайна ZFS.
>> Любопытно прочитать подробнее, что за косяки, и чем анноящие. Можно ссылочку?
> Тормозной он на их базах. Впрочем не только на них. И да,
> сервак БД это не файлсерв, там сабой БД хорошо бы кеш
> отдать. Так что позволить ФС захавать 100500 гигз оперативы чтобы выправить
> ее тормоза немеряным буфером уже не получается. А вот ораклу такой
> расклад как-то не очень нравится. Наверное это и мотивировало их затеять
> ФС которая была бы лучше, в том числе и с их
> базами.Нет, User294, ты не прав и сам об этом думаешь, но почему-то говоришь обратное.
После ухода основного разработчика Btrfs из Oracle в компанию к Стиву Возняку вряд ли что-либо путное получится из Btrfs, по крайней мере в ближайшее время. Эта ФС так и будет иметь статус экспериментальной (как и многие другие) и послужит памятником нереализованной мощи.
А ZFS тюнится по всем фронтам подо что угодно, под любые задачи, связанные с надёжным (и малонадёжным :) ) хранением данных. На уровне настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне методов поддержки целостности и верифицируемости реализуется куча стратегий использования. Сильное, но вместе с тем, слабое место ZFS — оперативная память, которой не хватает ВСЕГДА. ;)
> Нет, User294, ты не прав и сам об этом думаешь, но почему-то говоришь обратное.А это вообще не я придумал. Это кто-то из гуру (уж не помню кто, извини) анализировал устройство ФС. И ты уж прости, но я тем кто постоянно копается в ФС доверяю больше чем тебе с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не помешал там дефрагер, судя по тому что скорость работы ниже линейной в 10 раз.
> После ухода основного разработчика Btrfs из Oracle в компанию к Стиву Возняку
> вряд ли что-либо путное получится из Btrfs,А ничего что он заявил что он там будет работать над этой ФС? Собственно человек и род его занятий никуда не делись. А кто именно ему деньги заплатит - на что это влияет? От перемены мест слагаемых сумма не меняется.
> по крайней мере в ближайшее время.
А какое тому логическое обоснование? Ты процитировал факт. Но я не вижу ни единого аргумента почему должно быть так как ты сказал. Кстати говоря, Мавр сделал свое дело и наархитектил. Теперь очередь обычных разработчиков повкалывать. Если бы ты смотрел в логи коммитов - ты бы заметил что процесс идет и весьма недурно. А на новом месте Крис сможет оптимизить ФС под SSD. А у подобных накопителей большое будущее.
> Эта ФС так и будет иметь статус экспериментальной (как
> и многие другие) и послужит памятником нереализованной мощи.Ну ты мечтай, это не вредно и забавно выглядит со стороны.
> А ZFS тюнится по всем фронтам подо что угодно, под любые задачи,
> связанные с надёжным (и малонадёжным :) ) хранением данных.А кто-то имеющий отношение к саням или ораклу как раз и разжевывал что хреново ZFS с ораклем работала. CoW вообще потенциально клещится с базами данных из-за того что каждый хочет журналить и при том - по своему. Есть риск делать дважды одно и то же, если не сложилось и алгоритмы неудачно наложились друг на друга.
> На уровне настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне
> методов поддержки целостности и верифицируемости реализуется куча стратегий использования.Что сказать то хотел? То что ты выучил кучу умных слов - я понял. Но я не вижу в этом наборе слов признаков мыслительного процесса. Маркетинговый буллшит за таковой не считается.
> Сильное, но вместе с тем, слабое место ZFS — оперативная память,
> которой не хватает ВСЕГДА. ;)В базах данных ее не получится отдать ФС т.к. она самой БД нужна под ее кеши. Если и то и другое будет претендовать на кеш - сомнительно что выйдет что-то дельное. И есть риск сделать двойную работу, когда ФС отжурналит и БД отжурналит. И одно неудачно наложится на другое, спровоцировав лишнюю работу. У конкретного сочетания логик ZFS и оракла похоже все прошло по плохому сценарию в этом плане, так что оракл похоже остался недоволен и им надо что-то более подходящее.
>> Нет, User294, ты не прав и сам об этом думаешь, но почему-то говоришь обратное.
> А это вообще не я придумал. Это кто-то из гуру (уж не
> помню кто, извини) анализировал устройство ФС. И ты уж прости, но
> я тем кто постоянно копается в ФСГероев надо знать в лицо, а не только по имени. Так что не извеняю. :)
> доверяю больше чем тебе
> с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не
> помешал там дефрагер, судя по тому что скорость работы ниже линейной
> в 10 раз.Пул заполнен на 99%. HDD 2,5" 5400 rpm имеют максимум пропускной способности 55 МБ/с, средняя, соответственно, около 20 МБ/с, а не в 10 раз от 6 МБ/с.
>> После ухода основного разработчика Btrfs из Oracle в компанию к Стиву Возняку
>> вряд ли что-либо путное получится из Btrfs,
> А ничего что он заявил что он там будет работать над этой
> ФС? Собственно человек и род его занятий никуда не делись. А
> кто именно ему деньги заплатит - на что это влияет? От
> перемены мест слагаемых сумма не меняется.Возняку не нужен энтерпрайз по факту. Ему интересна эмбеддовка. Вот в этом направлении и будет развиваться Btrfs, так как кто оплачивает труд, тот и рулит развитием.
>> по крайней мере в ближайшее время.
> Ну ты мечтай, это не вредно и забавно выглядит со стороны.Когда там появится fsck? Или не нужен? :))
> А кто-то имеющий отношение к саням или ораклу как раз и разжевывал
> что хреново ZFS с ораклем работала. CoW вообще потенциально клещится с
> базами данных из-за того что каждый хочет журналить и при том
> - по своему. Есть риск делать дважды одно и то же,
> если не сложилось и алгоритмы неудачно наложились друг на друга.Для СУБД по большому счёту не нужна универсальная ФС. Им нужно блочное устройство. ZVOL обеспечивает это, а также включаемые по желанию свойства верифицируемости (checksum) на случай ненадёжных носителей.
>> На уровне настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне
>> методов поддержки целостности и верифицируемости реализуется куча стратегий использования.
> Что сказать то хотел? То что ты выучил кучу умных слов -
> я понял. Но я не вижу в этом наборе слов признаков
> мыслительного процесса. Маркетинговый буллшит за таковой не считается.Дык это не маркетинг. Это то, к чему уже привыкли на нормальных системах. А вы ещё в прошлом веке с отдельными менеджерами томов прыгаете, пытаясь сделать из них подобие RAID (относительно недавно внедрена проверка целостности md-зеркала в онлайне).
> У конкретного сочетания логик
> ZFS и оракла похоже все прошло по плохому сценарию в этом
> плане, так что оракл похоже остался недоволен и им надо что-то
> более подходящее.Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно не использует.
> Когда там появится fsck? Или не нужен? :))Когда fsck появится в ZFS? (риторический вопрос)
> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных
> системах.Кто привык? На каких системах? Списочек можно? Я везде вижу только ext'ы пока.
> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно
> не использует.Компания Oracle продает _основной_ свой продукт (СУБД) под Linux'ами и на ext'ах. Как альтернативу - на солярке и древнющем UFS. Но основное позиционирование, тем не менее, идёт не на солярку. Этого достаточно.
>> Когда там появится fsck? Или не нужен? :))
> Когда fsck появится в ZFS? (риторический вопрос)Джеф Бонвик дал понять, что fsck в ZFS не нужен из-за факта CoW-природы этой замечательной самоверифицирующейся файловой системой.
scrub с успехом заменяет классический fsck практически во всех случаях, как то: анализ проблем доступа к данным из-за физических особенностей среды хранения (вплоть до точного указания пути к повреждённому файлу), перестройка массива хранения. fsck не обладает важными свойствами, которые есть у scrub: fsck не обеспечивает точную идентификацию восстановленных данных с файлом, в котором они хранились (каталог .lost+found представляет собой сборник восстановленных данных, но не их файлов) — это делает невозможным восстановление из резервной копии именно того, что нужно за короткий промежуток времени.
>> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных
>> системах.
> Кто привык? На каких системах? Списочек можно? Я везде вижу только ext'ы
> пока.Понимаю — кругом одни Linux'ы. Не надоело? Может пора взлететь и расширить линию горизонта, а? Или "рождённый ползать летать не может" по определению классика тебе ближе по духу?
>> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно
>> не использует.
> Компания Oracle продает _основной_ свой продукт (СУБД) под Linux'ами и на ext'ах.
> Как альтернативу - на солярке и древнющем UFS. Но основное позиционирование,
> тем не менее, идёт не на солярку. Этого достаточно.В последних версиях промышленной ОС Solaris файловая система UFS поддерживается в статусе "legacy" и практически не используется в продакшене в качестве основной ФС.
> Джеф Бонвик дал понять, что fsck в ZFS не нужен из-за факта
> CoW-природы этой замечательной самоверифицирующейся файловой системой.ГДЕ, блин, гарантия того, что в коде ZFS нет ошибки, благодаря которой метаданные повредятся ещё в структурах в памяти, и благополучно запишутся с модификацией всех контрольных структур? А потом тупо не прочтутся, или прочтутся не оттуда, потому что FS будет считать, что всё у неё хорошо, и все цепочки "встроенных" проверок проходят? fsck в ext'ах допустим и хорош тем, что использует алгоритмы верификации целостности FS, которые трудно реализовать "на лету" - слишком много ресурсов нужно. И к остальным FS это тоже применимо.
> не обладает важными свойствами, которые есть у scrub: fsck не обеспечивает
> точную идентификацию восстановленных данных с файлом, в котором они хранились (каталогКогда у вас FS упадёт настолько, что перестанет монтироваться / будет выпадать в кору - вот тогда и вспомните про отсутствие fsck. Счастливчиков в инете уже навалом.
> Понимаю — кругом одни Linux'ы. Не надоело? Может пора взлететь и расширить
> линию горизонта, а?Линия горизонта Linux - какбэ уже практически целый мир применений. Далее расширять просто некуда, надо лишь охватывать неохваченные участки внутри.
>> Джеф Бонвик дал понять, что fsck в ZFS не нужен из-за факта
>> CoW-природы этой замечательной самоверифицирующейся файловой системой.
> ГДЕ, блин, гарантия того, что в коде ZFS нет ошибки, благодаря которой
> метаданные повредятся ещё в структурах в памяти, и благополучно запишутся с
> модификацией всех контрольных структур?Гарантии даёт господь бог и ZDB, очевидно. :))
> А потом тупо не прочтутся, или прочтутся
> не оттуда, потому что FS будет считать, что всё у неё
> хорошо, и все цепочки "встроенных" проверок проходят?Для этого есть протоколы верификации. Нет? Если появляются ошибки в непредсказуемых местах, то протоколы верификации никуда не годны и их нужно быстренько заменять на другие. Нет? Пока что ZFS держится бодрячком в самых неожиданных условиях моделирования отказов, которые другие ФС не переживают или переживают с потерями.
> fsck в ext'ах допустим
> и хорош тем, что использует алгоритмы верификации целостности FS, которые трудно
> реализовать "на лету" - слишком много ресурсов нужно. И к остальным
> FS это тоже применимо.Что же он такое использует, что трудно реализовать на лету? Вон, в ZFS и Btrfs не побоялись сделать верификацию данных и метаданных на лету. И ничего. Работает с приемлемой скоростью.
>> не обладает важными свойствами, которые есть у scrub: fsck не обеспечивает
>> точную идентификацию восстановленных данных с файлом, в котором они хранились (каталог
> Когда у вас FS упадёт настолько, что перестанет монтироваться / будет выпадать
> в кору - вот тогда и вспомните про отсутствие fsck. Счастливчиков
> в инете уже навалом.Когда падает CoW-ФС и не монтируется, для восстановления используется одна из последних подтверждённых транзакций CoW, только и всего. Техника письма CoW обладает одной замечательной способностью: не писать туда, где записано ранее, а искать, находить и записывать только на свободное место. Кстати, scrub работает только на смонтированном пуле — это его ключевое отличие от классического fsck для линуксовых ФС.
>> Понимаю — кругом одни Linux'ы. Не надоело? Может пора взлететь и расширить
>> линию горизонта, а?
> Линия горизонта Linux - какбэ уже практически целый мир применений. Далее расширять
> просто некуда, надо лишь охватывать неохваченные участки внутри."Неохваченные участки внутри", по-мне так, лучше оставить нубам, в противном случае приходит момент ощущения себя трактором на одной большой помойке. :))
> Гарантии даёт господь бог и ZDB, очевидно. :))Ну вот видите. Поэтому fsck обязателен. Ибо гарантии - только от всевышнего.
> Для этого есть протоколы верификации. Нет? Если появляются ошибки в непредсказуемых местах
У нас нет ошибок в труднодоступных местах (с)
Если сделать внутри ZFS полные верификации - оно будет лопатить одно чтение вечность. Полные верификации структур FS - это оффлайновый процесс, в онлайне они неприменимы в силу требований к производительности.> Пока что ZFS держится бодрячком в самых неожиданных
> условиях моделирования отказов, которые другие ФС не переживают или переживают с
> потерями.Зато самый ожидаемый отказ - потерю кеша с RAID-контроллера (села/вышла из строя BBU) оно не переносит вообще. Если интересно - можешь погуглить, как уже говорил, "счастливчиков" полно.
> Что же он такое использует, что трудно реализовать на лету? Вон, в
> ZFS и Btrfs не побоялись сделать верификацию данных и метаданных на
> лету.Для BTRFS делается оффлайновая чекалка. Онлайновые верификации не полны математически, если их сделать полными - оно будет тормозить.
> Когда падает CoW-ФС и не монтируется, для восстановления используется одна из последних
> подтверждённых транзакций CoWКоторую чем выцепать, при отсутствии fsck? Руками? Повторяю: оно не монтируется. И не импортится. Допустим, уходит в кору при попытке импорта. Ковырять руками - долго и нудно.
> scrub работает только на смонтированном пуле
А пул не монтируется. Вообще. Засада? Засада.
>> Гарантии даёт господь бог и ZDB, очевидно. :))
> Ну вот видите. Поэтому fsck обязателен. Ибо гарантии - только от всевышнего.
>> Для этого есть протоколы верификации. Нет? Если появляются ошибки в непредсказуемых местах
> У нас нет ошибок в труднодоступных местах (с)
> Если сделать внутри ZFS полные верификации - оно будет лопатить одно чтение
> вечность. Полные верификации структур FS - это оффлайновый процесс, в онлайне
> они неприменимы в силу требований к производительности."если бы да кабы".
>> Пока что ZFS держится бодрячком в самых неожиданных
>> условиях моделирования отказов, которые другие ФС не переживают или переживают с
>> потерями.
> Зато самый ожидаемый отказ - потерю кеша с RAID-контроллера (села/вышла из строя
> BBU) оно не переносит вообще. Если интересно - можешь погуглить, как
> уже говорил, "счастливчиков" полно.Вот поэтому ZFS не ставят на RAID и не надеются на BBU. Ну сколько об этом можно писать? Oracle официально не рекомендует эксплуатировать ZFS на аппаратных RAID.
>> Что же он такое использует, что трудно реализовать на лету? Вон, в
>> ZFS и Btrfs не побоялись сделать верификацию данных и метаданных на
>> лету.
> Для BTRFS делается оффлайновая чекалка. Онлайновые верификации не полны математически,
> если их сделать полными - оно будет тормозить.Бонвик расписал всю математику для самоверифицирующихся ФС задолго до появления Btrfs и реализовал её в ZFS. ZFS обладает внутренними механизмами самовосстановления и есть внешний отладчик ZDB. Ей не нужен ещё один (внешний инструмент восстановления) fsck, так как протокол восстановления у ней зашит внутри, работает как в онлайне, так и в оффлайне при монтировании пула. Это доказано на практике ГОДАМИ использования как в экспериментальных целях, так и в промышленных масштабах. Btrfs всё ещё имеет экспериментальный статус и не имеет специализированного отладчика типа ZDB, поэтому для неё необходим инструмент проверки корректности состояния в оффлайне.
>> Когда падает CoW-ФС и не монтируется, для восстановления используется одна из последних
>> подтверждённых транзакций CoW
> Которую чем выцепать, при отсутствии fsck? Руками? Повторяю: оно не монтируется. И
> не импортится. Допустим, уходит в кору при попытке импорта. Ковырять руками
> - долго и нудно."zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется — третьего не дано. И никакие fsck на убитом пуле ничего не восстановят, так как избыточности нет, данные из астрала fsck выцеплять не умеет.
>> scrub работает только на смонтированном пуле
> А пул не монтируется. Вообще. Засада? Засада."zpool import -F poolname". Прикинь, оно работает в некоторых случаях даже на FAULTED-пуле. ;) "Некоторые случаи", конечно, не относятся к сносу бошек у двух из трёх HDD в RAID-Z1 — в последнем случае данным попросту неоткуда взяться.
> "если бы да кабы".А если еще раз перечитать - поймёшь.
> Вот поэтому ZFS не ставят на RAID и не надеются на BBU.
Вот поэтому оно идёт в итоге в задницу, ибо хороший SAS-контроллер с большим кешем за счет оптимизации транзакций по шине и переупорядочиванию записей даст производительность, которая софтрейдам не приснится никогда. А если учесть, что софтрейды (и ZFS не исключение) прилично грузят CPU и общую системную шину (особенно зеркала), то вполне очевидно, что приличная доля ресурсов системы в итоге будет сожрана обменом с диском. Hint: для того, чтобы ZFS записать данные на 2 диска в софт-зеркале, нужно передать 2 копии данных по шине. Для того, чтобы записать данные на 2 диска в хард-зеркале, нужно передать 1 копию RAID-контроллеру.
> Бонвик расписал всю математику для самоверифицирующихся ФС задолго до появления Btrfs и
> реализовал её в ZFS. ZFS обладает внутренними механизмами самовосстановленияИ они так хороши, что немонтирующийся пул после слёта питания - не редкость (гуглим).
> в онлайне, так и в оффлайне при монтировании пула. Это доказано
> на практике ГОДАМИ использования как в экспериментальных целях, так и в
> промышленных масштабах.Тю. Кто её реально использует в промышленных масштабах, огласите список.
> "zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется
Именно. Кора. В общем, всё понятно, fail.
> "zpool import -F poolname"
Кора, либо отсутствие томов. Диски на месте. Подобных случаев в инете море.
>> "если бы да кабы".
> А если еще раз перечитать - поймёшь.Что конкретно? У тебя лично были вылеты с ZFS? У меня нет. У людей были и они их успешно решили, либо признали пул убитым по факту физического отказа и потери избыточности, но никогда из-за софтверной ошибки.
Что дальше скажешь?>> Вот поэтому ZFS не ставят на RAID и не надеются на BBU.
> Вот поэтому оно идёт в итоге в задницу, ибо хороший SAS-контроллер с
> большим кешем за счет оптимизации транзакций по шине и переупорядочиванию записей
> даст производительность, которая софтрейдам не приснится никогда.Опять "если бы да кабы". ZFS масштабируется на гибридную модель хранения HDD с SSD. В SAS используется только что-то одно: либо HDD, либо SSD — это основная причина низких эксплуатационных свойств аппаратных RAID.
> А если учесть, что софтрейды (и ZFS не исключение) прилично грузят CPU
Не говори того, чего сам не знаешь — ZFS не грузит CPU на дефолтных настройках. Алгоритм fletcher4 для 128k блоков практически нетребователен к ресурсам CPU.
Классические софтрейды тоже не CPU-зависимы, так как у них нет контрольных сумм для полос, которые верифицируются на лету в обычном режиме эксплуатации. Впрочем, в md-mirror такая фича недавно появилась и доступна опция верификации данных с обоих половинок зеркала в онлайне, но не сравнивал — не знаю как на скорости и на нагрузке на CPU это отражается.
> и общую системную
> шину (особенно зеркала), то вполне очевидно, что приличная доля ресурсов системы
> в итоге будет сожрана обменом с диском. Hint: для того, чтобы
> ZFS записать данные на 2 диска в софт-зеркале, нужно передать 2
> копии данных по шине. Для того, чтобы записать данные на 2
> диска в хард-зеркале, нужно передать 1 копию RAID-контроллеру.Поэтому для ZFS рекомендуют делать по одному LUN'у на шпиндель — так разгружается аппаратная часть и оптимизируются потоки I/O.
>> Бонвик расписал всю математику для самоверифицирующихся ФС задолго до появления Btrfs и
>> реализовал её в ZFS. ZFS обладает внутренними механизмами самовосстановления
> И они так хороши, что немонтирующийся пул после слёта питания - не
> редкость (гуглим).Не гуглим, а приводи точные ссылки на воркароунд. Ссылок нет — трепло.
Ссылка самовосстановления пула после отключения/слёта питания в этой теме: http://forum.ixbt.com/topic.cgi?id=11:43718
>> в онлайне, так и в оффлайне при монтировании пула. Это доказано
>> на практике ГОДАМИ использования как в экспериментальных целях, так и в
>> промышленных масштабах.
> Тю. Кто её реально использует в промышленных масштабах, огласите список.Sun использовала ZFS в мобильных BlackBox-контейнерах. Об этом ещё Шварц распространялся.
ZFS — основная файловая система в современных версиях Oracle Solaris.>> "zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется
> Именно. Кора. В общем, всё понятно, fail."Кора" на какой версии пула? "-F" отрабатывает только в ZFSv28 (стала готова для эксплуатации ровно год назад), остальное — "недообновление" и ССЗБ.
>> "zpool import -F poolname"
> Кора, либо отсутствие томов. Диски на месте. Подобных случаев в инете море.Хотя бы одну ссылочку привести не затруднит? А то у меня другие данные по монтированию современных Z-пулов, весьма благоприятные.
> Поэтому для ZFS рекомендуют делать по одному LUN'у на шпиндель — так
> разгружается аппаратная часть и оптимизируются потоки I/O.Если бы вы хоть чуть-чуть понимали аппаратуру - то не написали бы такой глупости. Доставка данных до LUN'а осуществляется по общим шинам, будь то процессорная или PCI-Express, или что еще. Ну да хрен с ней, с процессорной шиной, но вот городить по отдельному контроллеру на каждый шпиндель - как-то слегка накладно. И - да, не забываем, что пересылка данных на каждый шпиндель занимает еще шину памяти, угу.
> Не гуглим, а приводи точные ссылки на воркароунд. Ссылок нет — трепло.
Гугли.
http://kerneltrap.org/mailarchive/freebsd-fs/2010/12/18/6885731
http://freebsd.1045724.n5.nabble.com/ZFS-failed-after-hard-p... - тут автор отлечился, но через задницу
http://permalink.gmane.org/gmane.os.freebsd.devel.file-syste...
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March...
http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ - кора после повреждения данных, fsck бы спас
http://lists.freebsd.org/pipermail/freebsd-questions/2010-Ma... - висяки
http://mail.opensolaris.org/pipermail/zfs-discuss/2011-Novem... - нелечащиеся грабли
и так далее. учитывая нераспространенность FS, уже серьезно>[оверквотинг удален]
> Sun использовала ZFS в мобильных BlackBox-контейнерах. Об этом ещё Шварц распространялся.
> ZFS — основная файловая система в современных версиях Oracle Solaris.
>>> "zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется
>> Именно. Кора. В общем, всё понятно, fail.
> "Кора" на какой версии пула? "-F" отрабатывает только в ZFSv28 (стала готова
> для эксплуатации ровно год назад), остальное — "недообновление" и ССЗБ.
>>> "zpool import -F poolname"
>> Кора, либо отсутствие томов. Диски на месте. Подобных случаев в инете море.
> Хотя бы одну ссылочку привести не затруднит? А то у меня другие
> данные по монтированию современных Z-пулов, весьма благоприятные.
>[оверквотинг удален]
>> разгружается аппаратная часть и оптимизируются потоки I/O.
> Если бы вы хоть чуть-чуть понимали аппаратуру - то не написали бы
> такой глупости. Доставка данных до LUN'а осуществляется по общим шинам, будь
> то процессорная или PCI-Express, или что еще. Ну да хрен с
> ней, с процессорной шиной, но вот городить по отдельному контроллеру на
> каждый шпиндель - как-то слегка накладно. И - да, не забываем,
> что пересылка данных на каждый шпиндель занимает еще шину памяти, угу.
>> Не гуглим, а приводи точные ссылки на воркароунд. Ссылок нет — трепло.
> Гугли.
> http://kerneltrap.org/mailarchive/freebsd-fs/2010/12/18/68857312010 год...
> http://freebsd.1045724.n5.nabble.com/ZFS-failed-after-hard-p...
> - тут автор отлечился, но через задницуFreeBSD 8.1-STABLE.
> http://permalink.gmane.org/gmane.os.freebsd.devel.file-syste...
"I was able to boot to Fixit console from 8.2 LiveFS, prepare it for ZFS and mount the pool using "zpool import -Ff" command."
Почему я не удивлён?
> http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March...
2009 год...
> http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ - кора после повреждения данных
"размещено: 2011-02-04" — до появления ключа "-F" в команде монтирования FAULTED-пула. Опять мимо.
>, fsck бы спас
Не.
Вот "zpool import -F poolname" на ZFS спасает пул от окончательного разрушения, а "zpool scrub poolname" верифицирует и восстанавливает (если возможно) метаданные и данные, указывает полный список повреждённых файлов, которые подлежат восстановлению из архивных копий. А fsck в таком случае обычно всё портит и перемещает цепочки найденных байт в ничего незначащие файлы внутри каталога .lost+found. Оно нам надо? Для ZFS топорный fsck — точно нет, так как есть встроенные механизмы восстановления метаданных, и ещё есть более тонкий инструмент — ZDB.> http://lists.freebsd.org/pipermail/freebsd-questions/2010-Ma... - висяки
2010 год.
> http://mail.opensolaris.org/pipermail/zfs-discuss/2011-Novem... -
> нелечащиеся грабли
> и так далее. учитывая нераспространенность FS, уже серьезно"Нелечащиеся грабли" на ОДНОШПИНДЕЛЬНОЙ конфигурации пула (диск ST3808110AS, кстати), в которой в принципе отсутствует информация по избыточности для восстановления? :)) Ты это серьёзно?
Вот моя новость: http://www.opennet.me/opennews/art.shtml?num=30797
Какой бы год ни был - шанс вылезания данных проблем всё равно велик. Дело в том, что это юзают в основном энтузиасты, они и пишут. Пользователи солярки долбят саппорт оракла, в открытых форумах только 2-3 ситуации. Остальным по барабану.
> Героев надо знать в лицо, а не только по имени. Так чтоЯ не сотворяю кумиров, но вполне себе наматываю на ус умные мысли.
> не извеняю. :)
Герой-аналитик, мля. Облажаться в слове "извините" - это сильно.
>> помешал там дефрагер, судя по тому что скорость работы ниже линейной в 10 раз.
> Пул заполнен на 99%.Жесткач. Ты вообще представляешь как это выглядит? Ты свой мега-пул без ножа зарезал :)
> HDD 2,5" 5400 rpm имеют максимум пропускной способности 55 МБ/с,
Давай ты мне не будешь про них рассказывать, у меня вот под рукой пачка лежит. В среднем они свои 40-55 метров в секунду на линейном чтении отдают. Типично при линейном чтении можно ожидать около 50Мб/сек с диска.
> средняя, соответственно, около 20 МБ/с, а не в 10 раз от 6 МБ/с.
По моим наблюдениям, средняя там скорее мегов 40-50 в секунду получается. Больше на внешних треках, меньше на внутренних. А ты просто буратина, который загнал ФС в полную опу. Такое и дефрагер бы пару суток разгребал, если б он у тебя был, конечно. У тебя получилось много мелких фрагментов. Ну вот и скорость чтения далека от линейной. На томе мелкая лапша в не данные.
> Возняку не нужен энтерпрайз по факту. Ему интересна эмбеддовка. Вот в этом
> направлении и будет развиваться Btrfs, так как кто оплачивает труд, тот
> и рулит развитием.Какие-то высосанные из пальца утверждения. Впрочем, лично я только за, если бтрфс круто оптимизнут для SSD и подобных видов памяти.
> Когда там появится fsck? Или не нужен? :))
Вообще-то он там уже есть. Правда недоделанный. И еще ряд прикольных недеструктивных тулзов вытаскивающих файло без изменений в попорченную ФС. А в ZFS ни того ни другого нет и вообще не планируется даже. Когда выбор между фанатством к марке и доступом к данным - я за доступ к данным.
>> Есть риск делать дважды одно и то же, если не сложилось и алгоритмы неудачно наложились друг на друга.
> Для СУБД по большому счёту не нужна универсальная ФС. Им нужно блочное устройство.Теоретически - да. Практически - админить удобно все-таки файловую систему а не просто блочные устройства.
> ZVOL обеспечивает это, а также включаемые по желанию свойства верифицируемости
> (checksum) на случай ненадёжных носителей.Ну в общем ваши космические корабли бороздят просторы тихого океана, я правильно понял твой спич?
> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных системах.
Я так смотрю, ты привык и к скорости 6Мб/сек :)
> А вы ещё в прошлом веке с отдельными менеджерами томов прыгаете,
Слишком жирный наброс. Попробуй еще разок.
> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно не использует.
Они в unbreakable Linux его уже внедряют, если уж мы тут о фактах :)
>> Героев надо знать в лицо, а не только по имени. Так что
> Я не сотворяю кумиров, но вполне себе наматываю на ус умные мысли.Мысли без авторства ничего не стоят.
>> не извеняю. :)
> Герой-аналитик, мля. Облажаться в слове "извините" - это сильно.Тест на цепляние к словам ты не прошёл. Учись дальше, студент.
>>> помешал там дефрагер, судя по тому что скорость работы ниже линейной в 10 раз.
>> Пул заполнен на 99%.
> Жесткач. Ты вообще представляешь как это выглядит? Ты свой мега-пул без ножа
> зарезал :)Я-то? Представляю. А вот ты? Любишь потрындеть про CoW-ФС, а у самого небось только Ext4 в Ubuntu. :))
>> HDD 2,5" 5400 rpm имеют максимум пропускной способности 55 МБ/с,
> Давай ты мне не будешь про них рассказывать, у меня вот под
> рукой пачка лежит. В среднем они свои 40-55 метров в секунду
> на линейном чтении отдают. Типично при линейном чтении можно ожидать около
> 50Мб/сек с диска.Давай проспонсируй меня на покупку нескольких HDD, чтобы разгрузить пулы и добавить свободного пространства. От ещё трёх HDD 2,5" на 640 ГБ каждый я бы не отказался — сделал бы RAID-Z1-0 и скорость I/O пула повысилась бы до 60-70 МБ/с. ;)
Но HDD нынче дороги — наращивают упущенную выгоду от затопленных производств. :))
>> средняя, соответственно, около 20 МБ/с, а не в 10 раз от 6 МБ/с.
> По моим наблюдениям, средняя там скорее мегов 40-50 в секунду получается. Больше
> на внешних треках, меньше на внутренних.Никак не получается такая скорость на современных CoW-ФС, использующих малоскоростные шпиндели. Это скорость посекторной записи на RAW-девайсы малоскоростных шпинделей. От механики можно убежать только на SSD.
> А ты просто буратина, который загнал ФС в полную опу.
Была потребность — делаю. Чужие ощущения как бы не колышат — живу своими.
> Такое и дефрагер бы пару суток
> разгребал, если б он у тебя был, конечно. У тебя получилось
> много мелких фрагментов. Ну вот и скорость чтения далека от линейной.
> На томе мелкая лапша в не данные.На пуле медиатека. Периодически сгружаются туда заранее закачанные файлы, удаляются старые.
>> Возняку не нужен энтерпрайз по факту. Ему интересна эмбеддовка. Вот в этом
>> направлении и будет развиваться Btrfs, так как кто оплачивает труд, тот
>> и рулит развитием.
> Какие-то высосанные из пальца утверждения. Впрочем, лично я только за, если бтрфс
> круто оптимизнут для SSD и подобных видов памяти.Btrfs круто оптимизируют для Android-девайсов и заменят журналирующую Ext4, которая там не нужна до смерти. На большее она не способна.
>> Когда там появится fsck? Или не нужен? :))
> Вообще-то он там уже есть. Правда недоделанный. И еще ряд прикольных недеструктивных
> тулзов вытаскивающих файло без изменений в попорченную ФС. А в ZFS
> ни того ни другого нет и вообще не планируется даже.Открой для себя ZDB и удивись.
> Когда
> выбор между фанатством к марке и доступом к данным - я
> за доступ к данным.Ну и что ты ожидаешь получить от сдохшего пула, в котором два из трёх девайсов не двигаются? А, User294?
>> ZVOL обеспечивает это, а также включаемые по желанию свойства верифицируемости
>> (checksum) на случай ненадёжных носителей.
> Ну в общем ваши космические корабли бороздят просторы тихого океана, я правильно
> понял твой спич?Скорее — СУБД не нуждается в универсальной ФС, у неё должна быть своя структура хранения на RAW-девайсе. ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.
>> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных системах.
> Я так смотрю, ты привык и к скорости 6Мб/сек :)А что, мало разве? За счёт агрессивного кэширования часто используемых данных оно не ощущается вообще. Но когда сливаешь большой файл, то тут, да, наступают тормоза системы.
>> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно не использует.
> Они в unbreakable Linux его уже внедряют, если уж мы тут о фактах :)Да, внедряют — оптимистичная нотка два месяца назад появилась. :)
> ... Android-девайсов ... заменят журналирующую Ext4, которая там
> не нужна до смерти.Интересно, с чего вы взяли, что устройству, которое может быть выключено _в любой момент_ неприятным для FS образом, не нужна журналирующая FS? Механизмы левелинга, конечно, обеспечивают некоторое журналирование, но оно не учитывает особенностей FS.
>> ... Android-девайсов ... заменят журналирующую Ext4, которая там
>> не нужна до смерти.
> Интересно, с чего вы взяли, что устройству, которое может быть выключено _в
> любой момент_ неприятным для FS образом, не нужна журналирующая FS?Ext4 по дефолту журналирует только метаданные. А Btrfs по дефолту делает CoW и метаданным, и данным. Пользователям хочется лучшего, очевидно, они не хотят лицезреть кашу вместо данных при отлично работающей ФС.
> Механизмы левелинга, конечно, обеспечивают некоторое журналирование, но оно не учитывает особенностей FS.
Да что там учитывать? CoW-ФС в случае внезапного пропадания питания не делает из данных каши — это очевидное преимущество перед простым журналированием одних лишь матаданных в традиционных ФС. В мобильных девайсах не так важна скорость ФС, сколько надёжность хранения.
>>> В мобильных девайсах не так важна скорость ФС, сколько надёжность хранения.А еще там очень важно то, что объем памяти крайне невелик :) Поэтому ZFS там не будет никогда, потому что не будет никогда.
> Поэтому ZFS там не будет никогда, потому что не будет никогда.Опять bsdшников посетил заяц несудьбы...
> Мысли без авторства ничего не стоят.Логика дебила. А на что влияет авторство? Типа, если Пупкин сказал то это фигня, а если твой кумир - то сразу фигня перестает быть фигней, да? :)
>> Герой-аналитик, мля. Облажаться в слове "извините" - это сильно.
> Тест на цепляние к словам ты не прошёл. Учись дальше, студент.А вроде бы прокатило, хоть и жирновато было :)
> Я-то? Представляю.
Не, ты не представляешь. Ты доставляешь. Лулзы.
> А вот ты? Любишь потрындеть про CoW-ФС, а у самого небось только Ext4 в Ubuntu. :))
И btrfs есть. У меня вообще накопителей - хватает. Вот только у меня хватает ума подождать зеленого свистка вверх и посмотреть на результаты масс-внедрежки до того как что-то ценное туда сгружать. А так - оно работает. Даже в убунте. Правда если оно всерьез надо - кернель лучше юзать свеженький, багов там чинят много, твикают злобно, так что юзать кернель на 2-3 минорных версии старше последнего при нужности btrfs не совсем умно.
> Давай проспонсируй меня на покупку нескольких HDD,
А оно мне надо?
> чтобы разгрузить пулы и добавить свободного пространства.
Что самое смешное, это тебе уже не сильно поможет: та лапша которая там уже получилась никуда не денется.
> пула повысилась бы до 60-70 МБ/с. ;)
Не хочу ничего сказать но что-то меня цифра в 60Мб/с на такой куче оборудования что-то не вдохновляет.
> Но HDD нынче дороги — наращивают упущенную выгоду от затопленных производств. :))
Есть слегка такое дело. Цены уже не настолько конские, но все-таки.
> Никак не получается такая скорость на современных CoW-ФС, использующих малоскоростные шпиндели.
В принципе CoW фс вполне может попробовать трансформировать записи в нечто более-менее линейное. Тем более что у btrfs еще и дефрагер встроенный есть.
> Это скорость посекторной записи на RAW-девайсы малоскоростных шпинделей.
В идеальном случае, если ФС грамотно все делает, скорость записи и чтения должна быть близка к таковой. Но при 99% занятости пространства - любая ФС будет действовать не "как хочется" и "как было лучше", а "уж как получится наколупать из остатков по чайной ложке".
> От механики можно убежать только на SSD.
При таком стиле использования ФС у тебя и флеш протрется до дыр в момент. Просто потому что у встроенного контроллера не останется пространства для маневров и он будет вынужден на каждый пшик тереть блок и делать GC, чтобы хоть немного выкроить для разруливания запрошенной операции :)
>> А ты просто буратина, который загнал ФС в полную опу.
> Была потребность — делаю. Чужие ощущения как бы не колышат — живу своими.Кто ж тебе доктор? :D
> На пуле медиатека. Периодически сгружаются туда заранее закачанные файлы, удаляются старые.
Я бы сказал что на пуле с 99% использования и скоростью 6Мб/сек - идиотека :)
> Btrfs круто оптимизируют для Android-девайсов и заменят журналирующую Ext4, которая там
> не нужна до смерти. На большее она не способна.Вот будет лулзов если занюханная флешка андроида будет читаться в разы быстрее твоего многодискового ынтырпрайзного пула :)
> Открой для себя ZDB и удивись.
Я что-то не понял, ты мне предлагаешь самому чтоли по 1 файлу выколупывать с помощью вьюшки-дебагилки? А если файлов 10 000? А миллион?
> Ну и что ты ожидаешь получить от сдохшего пула, в котором два
> из трёх девайсов не двигаются? А, User294?Это ты про свой пул чтоли? :)
> Скорее — СУБД не нуждается в универсальной ФС, у неё должна быть
> своя структура хранения на RAW-девайсе.Теоретически ничему не противоречит, но админить неудобно + свою RAW девайсину 10-меговой sqlite базе - больно жирно, да? :)
> ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.
Ну и какие БД это могут юзать?
>> Я так смотрю, ты привык и к скорости 6Мб/сек :)
> А что, мало разве? За счёт агрессивного кэширования часто используемых данных оно
> не ощущается вообще. Но когда сливаешь большой файл, то тут, да,
> наступают тормоза системы.Ну вот, сам же и ответил на свой вопрос. Ясен пень, 6мб/сек это мало. Даже самая занюханная китайская флешка читается быстрее.
>> Они в unbreakable Linux его уже внедряют, если уж мы тут о фактах :)
> Да, внедряют — оптимистичная нотка два месяца назад появилась. :)Его и новелл внедряет и прочие. Пока не по дефолту - типа technology preview еще. Но вполне действующее preview и в общем то юзабельное уже. Просто пока никто не дает гарантий что оно production quality и fsck еще несколько недопиленный.
Основная причина почему ZVOL может не подходить, ровно такая же как от ZPL. Так как CoW никуда не делся. Просто убрали posix layer ... Стала чуть тоньше прослойка.RAW диски может использовать любая уважающая себя СУБД 8-) (Ну так как тут речь в основном про Оракл - то он может, в отличии от sqlite 8-))) который вы посчитали как СУБД)
Мне больше всего не хватает в btrfs следующих возможностей:
1. Гибридного хранения данных (про bcache не то - ибо привязка к блочному устройству)
2. Рейдом отличных от 0,1,10 (да читал что есть отдельные патчи, но когда сделают эту унификацию уровней raid по md, dm и btrfs - непонятно)
3. Нормальной миграции между различными уровнями RAID (тут тоже подвижки видятся)
4. Что б balance не рушил CoW на снепшотах
5. offline (!) - дедубликацию (у меня есть интервалы низкой нагрузки, во время которых я могу гонять balance и dedup-процессы)по-большому счету всем остальным можно пользоваться уже
4. не balance конечно, а defrag
> тут речь в основном про Оракл - то он может,Лично мне если честно на оракл вообще глубоко плевать :)
> в отличии от sqlite 8-))) который вы посчитали как СУБД)
Скулайт конечно такая немеряная субд :)) но известен он тем что довольно заметно тормозит на btrfs - судя по всему журнальная логика хреново накладывается.
> Мне больше всего не хватает в btrfs следующих возможностей:
[...]
> 4. Что б balance не рушил CoW на снепшотах
> 5. offline (!) - дедубликацию (у меня есть интервалы низкой нагрузки, во
> время которых я могу гонять balance и dedup-процессы)Интересно, а что если эту мыслю прям вот так вот и вфутболить им в список рассылки? Вроде бы дельно, а половина и мне бы пригодилась. Ну так, чтобы разработчики были в курсе :). Ну кроме той части которая и так задумана но злостный WIP.
> по-большому счету всем остальным можно пользоваться уже
Вполне согласен с такой оценкой - базовая механика вроде как уже более-менее устаканивается.
>> Мысли без авторства ничего не стоят.
> Логика дебила. А на что влияет авторство? Типа, если Пупкин сказал то
> это фигня, а если твой кумир - то сразу фигня перестает
> быть фигней, да? :)Видишь ли, "одним из первых эпистемологическую проблему ставит Парменид, вводя различия между истиной и мнением. Истина — это знание бытия, поэтому её главными критериями являются непротиворечивость, постоянство и вечность. Сократ разрабатывает один из первых методов познания — диалектику — прояснение идеи в процессе диалога. Истина здесь выступает в качестве консенсуса. Платон считал знания, приобретаемые людьми в течение жизни, воспоминанием уже существующего в душе человека знания. Аристотель закладывает основы рационализма, разрабатывая такой метод познания как аналитика."
>> Это скорость посекторной записи на RAW-девайсы малоскоростных шпинделей.
> В идеальном случае, если ФС грамотно все делает, скорость записи и чтения
> должна быть близка к таковой. Но при 99% занятости пространства -
> любая ФС будет действовать не "как хочется" и "как было лучше",
> а "уж как получится наколупать из остатков по чайной ложке".Ну вот и не удивляйся, что при свободном пространстве меньше 10-15 ГБ на CoW-ФС скорость ввода-вывода проседает на порядок от максимально возможной. Я не удивляюсь — я констатирую этот факт наблюдением.
>> От механики можно убежать только на SSD.
> При таком стиле использования ФС у тебя и флеш протрется до дырС чего бы? Я оставляю файлы на как можно больший срок. Стираю совсем уж ненужное и потерявшее актуальность. Перезаписываю не так часто.
>> ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.
> Ну и какие БД это могут юзать?ЛЮБЫЕ. И те, которые умеют создавать свои структуры на RAW, и те, которые лучше всего работают на какой-либо классической ФС, в которой отформатирован ZVOL. К примеру, ZVOL можно отформатировать в UFS2 (без журнала и Soft Updates, если нужно) или даже в FAT32, и на них разместить служебные файлы СУБД. Прикинь, FAT32 на RAID-Z3 пуле ZFS — линуксоиды не могут себе представить такого извращения. :)
>> Логика дебила. А на что влияет авторство? Типа, если Пупкин сказал то
>> это фигня, а если твой кумир - то сразу фигня перестает быть фигней, да? :)
> Видишь ли,Вижу кучу писанины. Судя по всему - витиеватая попытка отмазаться от прямого ответа на простой вопрос.
> Ну вот и не удивляйся, что при свободном пространстве меньше 10-15 ГБ
> на CoW-ФС скорость ввода-вывода проседает на порядок от максимально возможной. Я
> не удивляюсь — я констатирую этот факт наблюдением.Ну а что ты хотел? Чем меньше непрерывного свободного пространства - тем реже аллокатор сможет его отхапать. А т.к. CoW сам по себе городит фрагменты-выноски, все только усугубляется. Тем не менее, этот эффект есть и на обычных ФС. Просто на CoW он сильнее заметен за счет их природы.
> С чего бы? Я оставляю файлы на как можно больший срок. Стираю
> совсем уж ненужное и потерявшее актуальность. Перезаписываю не так часто.С того что записи будут довольно неудобные для физической реализации в том что реально есть на флеше. Там еще 1 слой похожей механики работает же. И для нее совсем не подарок если файловая система начнет оптом глушить запросами "много мелких блоков разбросанных по всему диску". Erase-блоки флеша - довольно крупные сущности.
>>> ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.
>> Ну и какие БД это могут юзать?
> ЛЮБЫЕ. И те, которые умеют создавать свои структуры на RAW,А там вон выше утверждают что CoW никуда не девается, ну и проблема с ним стало быть тоже. На btrfs можно просто отрубить CoW там где он мешается.
> разместить служебные файлы СУБД. Прикинь, FAT32 на RAID-Z3 пуле ZFS —
> линуксоиды не могут себе представить такого извращения. :)Я могу себе представить очень много извращений. Но не всегда могу себе представить нафиг они нужны.
> я тем кто постоянно копается в ФС доверяю больше чем тебе
> с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы неБлджад, чего-то я сразу не догадалсо. У него что, RAID1 на одном диске? xD
>> я тем кто постоянно копается в ФС доверяю больше чем тебе
>> с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не
> Блджад, чего-то я сразу не догадалсо. У него что, RAID1 на одном диске? xDУ меня-то?
На посмотри: [посмотрели и хватит]
> У меня-то?
> На посмотри: [посмотрели и хватит]И с 4 дисками оно даёт 6мб/сек? Поздравляю, вы достигли невиданных высот производительности.
>> У меня-то?
>> На посмотри: [посмотрели и хватит]
> И с 4 дисками оно даёт 6мб/сек? Поздравляю, вы достигли невиданных высот производительности.Кто сказал, что с четырёх?
6 МБ/с — это скорость I/O у заполненного на 99,9% пула raid-z1, когда свободного места около 1-2 ГБ.
> 6 МБ/с — это скорость I/O у заполненного на 99,9% пулаНастолько эпичного забивания микроскопом гвоздей я давненько не видал. Жги еще :)
> А ZFS тюнится по всем фронтам подо что угодно, под любые задачи,
> связанные с надёжным (и малонадёжным :) ) хранением данных. На уровне
> настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне
> методов поддержки целостности и верифицируемости реализуется куча стратегий использования.Вот да, так сейчас прямо все сели, и начали годами тюнить вместо того, чтобы работать.
Давай начистоту: это реально пригодно только для файлопомоек с документами. Всё остальное сидит на ext'ах в силу их предсказуемости. Для БД оно не пригодно в принципе в силу двойного кеширования. Для почтовика - в силу того, что захлебнётся под sync'ами и write barrier'ами. Для web-сервера под сомнением, зависит от специфики нагрузки. Где-то, может быть, будет юзабельно. Для виртуалок непригодно в силу неизвестности специфики.
В винду бы её портнуть. Там оного сильно не хватает, а большинство компаний документы хранят именно на винде.
>А вот ораклу такой расклад как-то не очень нравится. Наверное это и мотивировало их затеять ФС которая была бы лучше, в том числе и с их базами.Интересная мысль, кстати...
Соглашусь, что интересная. Интереснее мысли использовать COW файловую систему для размещения БД может быть только мысль заменить одну COW файловую систему на другую COW файловую систему. =)
> БД может быть только мысль заменить одну COW файловую систему на
> другую COW файловую систему. =)У них все-таки есть отличия в логике аллокаторов. Более того - btrfs в принципе может и не делать CoW, если не надо. Если не ошибаюсь, идея была сделать выбор использовать ли CoW чуть ли не пофайлово.
Немного из их вики про опцию nodatacow:
> Performance gain is usually < 5% unless the workload is random writes to large database filesДостаточно прозрачный намек, правда? :)
COW чисто для примера, конечно в нем только часть проблемы. Совершенно очевидно, что ни та ни другая ФС не затачивалось под базы данных.
Наверно можно отказаться от всех плюшек вроде снэпшотов, сжатия, чексумм и пр., поменять алгоритм работы ФС, приставить парочку костыликов и получить близкую к ext3/4 производительность. Но, повторюсь, для меня очевидно, что проектировали обе ФС не под эту задачу.Наверно самый прямой способ исправить производительность ― это оптимизировать саму СУБД под работу с этими ФС. Но ИМХО еще прямее, производительнее и универсальнее реализовать необходимый функционал внутри СУБД и не зависеть от файловой системы.
>COW чисто для примера, конечно в нем только часть проблемы. Совершенно очевидно, что ни та ни другая ФС не затачивалось под базы данных.ничего подобного. чуть ниже написал.
и да, не затачивалось под базы данных вообще и затачивалась под одну конкретную субд - разные вещи.можете сравнить:
http://docs.oracle.com/cd/B28359_01/server.111/b28318/logica...
>Oracle Database allocates logical database space for all data in a database. The units of database space allocation are data blocks, extents, and segments.и
https://btrfs.wiki.kernel.org/index.php/Main_Page
>The main Btrfs features available at the moment include:
> Extent based file storage...
и да, оракл в своём унбрикэйбл линухе для ынырпрайзу уже предлагает бтр.
>Oracle Database allocates logical database space for all data in a database. The units of database space allocation are data blocks, extents, and segments.Писал же, если и заточат, то в большей степени СУБД под ФС, чем наоборот. И не вижу в этом логики, потому что все что надо можно реализовать в СУБД: снэпшоты, компрессию, размещение на нескольких томах, репликацию и много чего еще и многое уже реализовано и поверх ext4 это будет грубо говоря на пару порядков меньше тупить при записи и на порядок при чтении чем на Btrfs.
> и да, оракл в своём унбрикэйбл линухе для ынырпрайзу уже предлагает бтр.
Крайне рад за них и ничего против не имею. Сам юзаю в продакшне осторожно. Оно оправдано для большинства юзкейсов. Я тут конкретно про размещение базы данных говорю. Ну еще про образы виртуалок можно вспомнить, такая-же IO содомия получается.
ответил ниже (давайте туда обсуждение и перенесём, если охота. а то прыгать надоело).только это уточню
>И не вижу в этом логики, потому что все что надо можно реализовать в СУБД: снэпшоты, компрессию, размещение на нескольких томах, репликациювсё это в оракле работает в стиле fuse на традиционных фс.
со всеми вытекающими.
с другой стороны воспользоваться преимуществами бтр сейчас может только субд оракл.
ну и если напишут двигун к мускулю.
который тоже оракл.
для всех остальных субд лучшим решением до сих пор являются (у в будут являтся. ибо даже нет подвижек) фс в стиле extX/ufs/raw/...
Да блин уже непонятно где что отвечать, три одинаковых треда. =)>с другой стороны воспользоваться преимуществами бтр сейчас может только субд оракл.
Если это действительно так, то отчасти соглашусь. Но где посмотреть не теоретические пруфы?
Не вижу причины, почему Оракл может допилить свою СУБД, а остальные не могут.
> Да блин уже непонятно где что отвечать, три одинаковых треда. =)ага :D
>Если это действительно так, то отчасти соглашусь. Но где посмотреть не теоретические пруфы?
у меня нет инсайдерской инфы. :D
могу сказать что мэйсон эту часть уже завершил.
а вот найти контору с поставками подобных хранилищ... хм, может его партия бросила на другую целину? :D
>могу сказать что мэйсон эту часть уже завершил.Тот который из Оракла ушел? =)
угу. :Dзыж
ну дык элоп тоже вон на финов работает. :D
> ну дык элоп тоже вон на финов работает. :DИнтересное понимание работы НА финов. Мне кажется что он поработав на них угробит контору + может быть патентов немного отожмет. А финам останется зaкaпывать высушенный трупик ноклы.
неа.
отожмут все (ВСЕ!!!) патенты.зыж
уж человеку, выжевшему в 90-е в России, это надо понимать чётко. :D
> COW чисто для примера, конечно в нем только часть проблемы.Проблема выглядит так: есть бд. С журналом. Обычная транзакция через журнал для CoW ФС вызовет CoW и для журнала и для БД. Итого? Два выноска вбок (журнальный и БДшный). Бессмысленно и беспощадно. Фрагментация растет, появляется куча мусора, лишних действий сделано вагон. По сути - отжурналили дважды. Нафига?
> Совершенно очевидно, что ни та ни другая ФС не затачивалось под базы данных.
Судя по таким фичам как nodatacow, которые по задумке применимы аж к отдельным файлам, логично предположить что оракл просто попросил архитекта придумать что-нибудь по поводу хреновой работы CoW с "большими базами данных". Ну и придумали - если мешается, пусть будет отключабелен для "файлов с большими базами данных" :)
> Наверно можно отказаться от всех плюшек вроде снэпшотов, сжатия, чексумм и пр.,Эти плюшки, будучи применены к "большой БД с журналингом" просто угробят производительность в ноль и засрут том кучей фрагментов, при том минимум половина из них вообще отбабахана на временные служебные сущности aka кусок журнала.
А на кой хрен вам снапшоты журнала и БД, если их журналирование и так обеспечивают консистентность? Более того, откатив базу транзакций на устаревший снапшот - можно сказочно попасть на бабки, например. Журнальная логика по идее обеспечивает "все или ничего", так что или операция доходит до финиша, или полностью отменяется. А вы предлагаете выдать юзеру бабло, потом откатить снапшот (стало быть, забыв о том что выдали). И....и еще раз выдать?! Посколько баланс счета откатился на дотранзакционное состояние! Откат снапшота БД не может вынуть купюры из кармана юзера, поэтому откат в дотранзакционное состояние на этот момент времени уже будет "немного неполным". Получится состояние БД не коррелирует с фактическим состоянием дел. Получится сломанная база с недостоверными данными + сказочный залет на бабки. Юзер с радостью обнаружит что с него забыли списать то что у него звенит в кармане. И снимет еще раз.
> поменять алгоритм работы ФС, приставить парочку костыликов и получить близкую к
> ext3/4 производительность.Ну так хорошо же что не придется делать лоскутное одеяло из разных файловых систем, обойдясь одной, а хотя-бы и с разными параметрами для разных файлов. И да, вам не кажется что насильно кормить плюшками того у кого на них аллергия и кому от этого плохеет - не совсем гуманно и правильно? :)
> Но, повторюсь, для меня очевидно, что проектировали обе ФС не под эту задачу.
Видимо оракл попросил чтобы и вон та задача тоже могла бы там культурно отрабатывать. Архитект малацца - особо не парился и просто хряпнул мечом со всей дури по Гордиеву узлу, вот так вот влобешник удавив проблему :)
> Наверно самый прямой способ исправить производительность ― это оптимизировать саму
> СУБД под работу с этими ФС.Теоретически - это ничему такому не противоречит, в принципе это повторяющийся функционал. Особенно если вспомнить что оракль как минимум раньше мог работать на RAW разделах, не нуждаясь в ФС. Ну то-есть ФС и БД - это достаточно похожие идеи, поданные под разным видом соуса :). Практически - вам имхо не понравится поведение btrfs при попытке хреначить много мелких транзакций. Потому что она для этого не оптимизировалась.
> Но ИМХО еще прямее, производительнее и универсальнее реализовать
> необходимый функционал внутри СУБД и не зависеть от файловой системы.Внезапно, оракль помнится умел работать на RAW разделах - совсем без ФС. Это по идее удобнее всего для базы - оверхеда от ФС нет совсем. Так что баян! Зато это оказалось нифига не удобно для сисадминов в плане администрирования...
>Проблема выглядит так: есть бд. С журналом. Обычная транзакция через журнал для CoW ФС вызовет CoW и для журнала и для БД. Итого? Два выноска вбокхинт
UUID=6c9c74fd-da69-432c-8b64-5317c6c79979 /u01 btrfs defaults,subvol=u01,autodefrag,inode_cache 0 0
UUID=6c9c74fd-da69-432c-8b64-5317c6c79979 /u02 btrfs defaults,subvol=u02,autodefrag,nodatacow,inode_cache 0 0где /u02 - субволум для журналов.
зыж
дальше полный булшит из-за не понимания вышеприведённого хинта.
> где /u02 - субволум для журналов.Ну, вырубили datacow для журнала, скостив геморрой CoW'у по совершению бесполезной работы над журналом. В чем тут булшит? На именно это и намекалось вроде.
хм. вот в этом
>Эти плюшки, будучи применены к "большой БД с журналингом" просто угробят производительность в нольи далее по тексту.
как создать субволум на работающей системе в 3 секунды и смотировать его с нокоудата тоже рассказать?
>>Эти плюшки, будучи применены к "большой БД с журналингом" просто угробят производительность в ноль
> и далее по тексту.Так в чем предъява? В общем случае будет вот так. Без специальной доработки БД - угробят. А то что оракль насколько я понял хочет доработать (или уже?) субд чтобы так делать было не надо - логично. А они что, у себя подритовали логику журналинга, чтобы на CoW более естественно ложилось? Если что - я ни разу не оракловый DBA и потому не слежу за деталями развития их баз.
> как создать субволум на работающей системе в 3 секунды и смотировать его
> с нокоудата тоже рассказать?Мне - нафиг не надо. Я сам с btrfs периодически играюсь в ожидании зеленого свистка о готовности к продакшну. Изенам и прочим - да как хотите, мне похрен. Я думаю что изенообразные лучше будут наслаждаться своими 6Мб/сек, мужественно преодолевая невзгоды бсджного жития :)
> Я сам с btrfs периодически играюсь в
> ожидании зеленого свистка о готовности к продакшну.Жди свистка, а мы будем пользоваться. :))
> Изенам и прочим -
> да как хотите, мне похрен. Я думаю что изенообразные лучше будут
> наслаждаться своими 6Мб/сек, мужественно преодолевая невзгоды бсджного жития :)А куда деваться? У меня спонсоров нет, чтобы купить ещё шпинделей. Или ты проспонсируешь столь ответственную операцию в период яростного отъёма денег на новые заводы? :))
> А куда деваться? У меня спонсоров нет, чтобы купить ещё шпинделей.Не надо спонсоров. Выкиньте ZFS, вставьте ext4 (ну не мамонта UFS же), и поимейте, наконец, нормальную производительность на имеющемся железе.
>> А куда деваться? У меня спонсоров нет, чтобы купить ещё шпинделей.
> Не надо спонсоров. Выкиньте ZFS, вставьте ext4 (ну не мамонта UFS же),
> и поимейте, наконец, нормальную производительность на имеющемся железе.Меня устраивает. По железу я пока "дауншифтер". :) Вот когда появятся 2,5" винчестеры 1-2 ТБ за приемлемую, а не конскую цену, как сейчас, тогда обновлю парк. А пока на классические Ext4/UFS на устаревшем (а значит, снижающем свою надёжность) железе я переходить не собираюсь — данные важнее скорости. Городить огороды из классических софтверных RAID муторно, много точек отказов на каждом из уровней: HDD, драйвер контроллеров, "изношенная" дешёвая оперативная память, недостаточная верификация данных. ZFS все потенциальные точки отказов заворачивает на себя, и если пул перестаёт работать не из-за поломки HDD, то он точно останется в непротиворечивом состоянии. Для классических RAID любая поломка на линии пересылаемых данных, не связанная с HDD, скорее всего приведёт к деградации массива и поиску дорогих запчастей.
> и поимейте, наконец, нормальную производительность на имеющемся железе.Ну если он и ее на 99% загадит - скорость будет тоже так себе. Хотя клиника будет не настолько хардкорная, имхо.
Чего я не понимаю так это вот чего: за цену 3 медленных ноутбучных 2.5" вполне можно купить 2-3 нормальных, весьма объемистых 3.5", которые и более надежны при длительной работе. Если роялит шум и нагрев - так в природе есть "зеленые" модели, у которых скорость вращения ниже "обычных" (обычно 5400RPM или около того). В счет чего они меньше жрут, меньше греются и намного тише елозят головами. При этом свободного места будет в 2-3 раза больше за те же деньги. Для HTPC-образных файлозавалов без требования к скорости - просто клад. Но изен как обычно все сделал через ... то самое место :).
Нет, мне самому нравятся 2.5" винчи. Клевые мелкие штучки, довольно емкие уже. Просто микроскопом забивать гвозди - медленно и геморройно. И не факт что микроскоп долго протянет в таком режиме.
> Жди свистка, а мы будем пользоваться. :))Да пожалуйста, наслаждайтесь вашими 6мб/сек :)
> ты проспонсируешь столь ответственную операцию в период яростного отъёма денег на
> новые заводы? :))Да ну нафиг, мне и так хорошо. И вообще, предлагаю так и оставить как эталон производительности. Будем в iZEN'ах производительность мерять. Ну там 20x - уже ничего так для десктопного HDD, etc :)
>Соглашусь, что интересная. Интереснее мысли использовать COW файловую систему для размещения БД может быть только мысль заменить одну COW файловую систему на другую COW файловую систему. =)вы работали когда-нибудь с субд оракл?
если работали, то увидите прямую аналогию даже в их терминах - блоки, экстенты и тд.
так вот, если субд переложит это на фс, то избавится от двойной буферизации - это раз, лишнего переключения контекстов юзер-кернел спейс - это два.
Вот именно аналогия.
Только наоборот вводят двойную буферизацию, трэдизацию, процессозацию и другую двойную ацию. Короче дублируют функционал СУБД еще и в ФС.
И где тут логика? Будут переносить функционал из своей прелестной СУБД в файловую систему под GPLv2, чтобы конкурентного преимущества не было больше?
Логика в вызове функций фс там, где сейчас используется юзерспейс код.
С зфс ещё хлеще - держать мапирование своих экстентов с зфс-ными блоками.
А конкурентное преимущество в увеличении ещё больших попугаев в ИХ субд.
То что на такой фс можно ещё и файлопомойку развернуть - дело 10-е. И с бизнесом их не пересекается.
Ещё раз - оракловая субд будет там отлично жить. А у конкурентов? Перепишут свои субд под логику оракл? Врядли.
Ну к мусклу можно двигун смастерить. Благо мускуль такую архитектуру имеет. Но! Внизапно, а чей сейчас мускуль то?
Вот и получается, что оракл будет работать и в кластерах, и на миксах ссд-винты, и на крипто-зипо-дедупло,.....
А для нормальной работы конкурентов старый лвм-райд и тд. При этом оракл и тут работает тоже.
>Логика в вызове функций фс там, где сейчас используется юзерспейс код.
>С зфс ещё хлеще - держать мапирование своих экстентов с зфс-ными блоками.Да, логика есть конечно, но только если мы говорим про некую гипотетическую файловую систему, а не про ZFS и Btrfs, которые (с этого и начался разговор) ну просто совсем провальны в работе с очень большим количеством мелких операций.
>Ещё раз - оракловая субд будет там отлично жить. А у конкурентов?
Да, если они как-то очень хитро и активно подгоняют свою СУБД под ФС, а ФС под СУБД, тогда логика есть. Но пока об этом ничего не говорит. Может быть под ZFS, про нее мало знаю, но Btrfs уже давно самостоятельно и неспешно развивается.
>Да, если они как-то очень хитро и активно подгоняют свою СУБД под ФС, а ФС под СУБД, тогда логика есть. Но пока об этом ничего не говорит. Может быть под ZFS, про нее мало знаю, но Btrfs уже давно самостоятельно и неспешно развивается.а субд оракл плевать на такие клинические случаи.
у их субд запись грязных блоков идёт либо по контрольной точке (раз в 3 секунды), либо по коммиту транзакции (для не асинхронных).
в любом случае - мелких файлов нет, а если все данные транзакции ещё и попадут в одно место на диске - ещё лучше. раз данные совместны, то и селекты будут их запрашивать вместе с гораздо большей вероятностью.>но Btrfs уже давно самостоятельно и неспешно развивается.
как и ocfs2.
что не мешает ораклу использовать её в самых крутых инсталяциях.
а если ещё вспомнить про ceph, то с бтр оракл сможет делать инстансы ещё больше в перспективе.
>в любом случае - мелких файлов нет,С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.
Один из костыльных и способов оптимизировать это дело вроде
>у их субд запись грязных блоков идёт либо по контрольной точке (раз в 3 секунды)тоже очевиден. Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.
>С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.в оракловом случае не попадают.
наоборот, ораклу пофиг на фрагментацию всего файла (большого файла. угу. на заметку).
но не плевать на фрагментацию отдельных кусков этого файла.
и эти куски очень сильно согласуются с контрольными точками и коммитами транзакций.
(по большому счёту таблицы/индексы/../экстенты играют роль каталогов в некой фс.
и эта фс создана поверх набора больших файлов в реальной фс операционной системы).>Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.
очевидно да.
но это - либо менять структуру тогоже постгри/огнелис/прогресс/дб2, либо писать что-то новое. а клинический ынтырпрайз на енто не пойдётЪ. :D
потом (следим за новостями с попкорном) появляются новости очередного эксадата с поддержкой вот такоговот железа с крипто/зипо/дедупо/... на уровне ядра с сопроцесоо/фпу/.. поддержкой.
и понимаем, что 1) это все только в унбрикэбл 2) у конкурентов это только в юзерспейсе 3) достичь таких объёмов в стиле fuse даже в теории низя.
как то так. вот.
зыж
к этому
>эксадата с поддержкой вот такоговот железа с крипто/зипо/дедупо/... на уровне ядра ... что 1) это все только в унбрикэблтипа такого - http://www.fusionio.com/platforms/
куда мэйсон и свалил. :D
>>С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.
> в оракловом случае не попадают.
> наоборот, ораклу пофиг на фрагментацию всего файла (большого файла. угу. на заметку).
> но не плевать на фрагментацию отдельных кусков этого файла.
> и эти куски очень сильно согласуются с контрольными точками и коммитами транзакций.И фрагментация тоже не многое объясняет, на SSD она мало влияет на скорость, тем не менее вот недавнее сравнение нашел. ИМХО правдоподобно.
http://www.mysqlperformanceblog.com/2012/05/22/btrfs-probabl.../
Если хочется докопаться до сути, наиболее правдоподобное на мой взгляд объяснение феномена было в мэйллистах федоры. http://comments.gmane.org/gmane.linux.redhat.fedora.devel/15.... Второй пост и далее по треду. Лично мне достаточно длительного существования проблемы и отсутствия решения, чтобы говорить, что не под эти задачи систему проектировали изначально.>>Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.
> очевидно да.
> но это - либо менять структуру тогоже постгри/огнелис/прогресс/дб2, либо писать что-то
> новое. а клинический ынтырпрайз на енто не пойдётЪ. :DТот же мускуль что-то порядка десяти сторадж бэкендов имеет, а значит и в МарияДБ можно запилить еще скажем один. Во всяком случае не верю, что Оракл не верит, что конкуренты не способны воспользоваться его технологиями.
> и понимаем, что 1) это все только в унбрикэбл 2) у конкурентов
> это только в юзерспейсе 3) достичь таких объёмов в стиле fuse
> даже в теории низя.
> как то так. вот.Ну да и поэтому они запилили бы свой модуль в свое анбрикабл ядро для своей базы данных, а не ФС для "враждебной" общественности.
Слишком много и по-кругу.
Опять.
Вот они запилили ocfs2. Для всех.
Кто пользуется?
В их сегменте интересов только они.
При чём в хайэнде.
Не в их сегменте?
Я. И такие как я. На файлопомойках со снепшотами, корзинами и тд.
Получить с меня балобосы низя. Получить багтрекер - можно. И получают.
Тоже и с бтр.
ну если так, то просто рекомендую при случае попробовать более-менее загруженную базу на Btrfs положить. Тупняк настолько суров, что в него сложно поверить не проверив на своем опыте.
Только не надо мне говорить, что вы ораел дба :DЗыж
Кстати клал. Не продуктивную, но... лучше чем зфс с настройками по феньшую.
И да, бтр для будущих версий. Которые будут на неё рассчитаны. Это новость?
Думаю как раз перед ними бтр и станет продакшн рэди.
>Только не надо мне говорить, что вы ораел дба :DНет, божеупаси админить это чудовище. У меня постгрес и немного мускулей, если считать только тех которые под нагрузкой, а так какой экзотики только нет. Я имел в виду любую СУБД на Btrfs погонять, но если можете Оракл, тем интереснее результат.
та не,
оракл не так страшен, как его малюют.>Я имел в виду любую СУБД на Btrfs погонять, но если можете Оракл, тем интереснее результат.
для любой субд бтр с нокоудата.
для оракла - нет.
вот в этом и интерес оракла кстати :D
С nocowdata запись при большом количестве транзакций раза в 2 быстрее, остальное так же. При этом естественно не работают снэпшоты, а так же сжатие данных. Вот мы и отказались от сразу двух жирных плюшек.
Допустим на Оракл ДБ магическим образом не будет влиять COW и допустим она еще в 2 раза быстрее за счет какого-нибудь агрессивного кэширования. Но отставание то от ext4 на порядки под нагрузкой!
> Но отставание то от ext4 на порядки под нагрузкой!Не вижу никаких фундаментальных причин для того чтобы было так: в случае nodatacow оно по сути что-то типа ext4 и получится ;)
да.
но! это субволум! и там же! и только для журналов! и в 3 сек добавить-удалить. :D
> но! это субволум! и там же! и только для журналов! и в 3 сек добавить-удалить. :DЯ так смотрю, такие плюшки не только мне нравятся :)
>С nocowdata запись при большом количестве транзакций раза в 2 быстрее, остальное так же.ТОЛЬКО.. ДЛЯ.. ЖУРНАЛОВ!!!
>При этом естественно не работают снэпшоты, а так же сжатие данных.журналам не нужны. журналы сами по себе снэпшоты.
зыж
>Допустим на Оракл ДБ магическим ....далее троллинг.
вы всё уже поняли, я уверен. :D
не айзен чай.
> С мелкими файлами проблем у Btrfs нет.У нее есть проблемы с "множеством мелких транзакций". Сложно знаешь ли на круизном теплоходе маневрировать так же как на прогулочном катере на 2 персоны.
да.
но у оракла все транзакции крупные.
он сбрасывает блоки на диск по чекоуту (3 раза в сек) или по коммиту.
а коммит (как говорит том кайт. и правильно говорит) в оракле надо делать только из соображений бизнес-логики, а не "как можно чаще" как в мссиквеле.зыж
>он сбрасывает блоки на диск по чекоутуи бтр за одну(!) операцию выделит ему столько места, сколько попросит.
сразу.
а не тюнингованный эквивалент в зфс.
и не энсать секунд как в уфс.ззыж
именно поэтому ext4 тоже не плоха - эктенты таки есть.
это как с торрентами.
но в бтр это ещё и в рамках одного файла. ей пофиг.
> и бтр за одну(!) операцию выделит ему столько места, сколько попросит.сразу.
> а не тюнингованный эквивалент в зфс.
> и не энсать секунд как в уфс.Во, DBA явно заценил работу экстентного аллокатора. А бздуны орут что оно не нyжно. Лолки! :)
билятттт....тт...ъъъ
давно жду.
учавствую.
верю.
...
и тд и тп.
>А вот ораклу такой расклад как-то не очень нравится. Наверное это и мотивировало их затеять ФС которая была бы лучше, в том числе и с их базами.И намного быстрее их базы на Btrfs работают, чем на ZFS? Чисто из академического интереса спрашиваю.
> И намного быстрее их базы на Btrfs работают, чем на ZFS? Чисто
> из академического интереса спрашиваю.На бтре они работают, на ZFS - нет (на любой более-менее серьезной нагрузке система встает колом).
Неужели?"Oracle на ZFS: Учимся готовить кошек, часть I": http://yvoinov.blogspot.com/2011/01/oracle-zfs-i.html
Готовили, пробовали, знаем.
Не то.Зыж
Ха. Желаю вам быть оракл дба на зфс.
А то на металинке сразу в сад.
> Ха. Желаю вам быть оракл дба на зфс.Когда изен умрет и попадет к чертям в ад, он будет админить оракл на zfs. Вечно.
>И намного быстрее их базы на Btrfs работают, чем на ZFS? Чисто из академического интереса спрашиваю.думаю что следующий шаг - это внесение изменений в саму субд.
их архитектуры совместимы настолько, что субд сможет переложить часть функциональности на бтр. с zfs этого не получится в принципе.зыж
и да, лучшие результаты у сбд оракл получаются на раудевайсах (без фс вообще).
выигрыш 20-30%. а это ой как не мало.
но, в последних версиях субд от раудевайсов отказались в силу неудобства их обслуживания.
думаю бтр найдёт своё место в http://docs.oracle.com/cd/E11882_01/server.112/e18951/whatsn...
>думаю что следующий шаг - это внесение изменений в саму субдЯ это и говорил, соответственно согласен.
>их архитектуры совместимы настолько, что субд сможет переложить часть функциональности на бтр.но зачем
>зыж
>и да, лучшие результаты у сбд оракл получаются на раудевайсах (без фс вообще).Это очевидно.
А у них есть план восстановления после хардверного факапа или внезапного кернел паник, или резета, сравнимый по скорости с журналируемой ФС? ИМХО это большая ошибка исключать такой ход развития событий.
И сам не мерил, но одна бабка сказала, что на ext4 базы данных по производительности приближаются к просто блочному девайсу.
>А у них есть план восстановления после хардверного факапа или внезапного кернел паник, или резета, сравнимый по скорости с журналируемой ФС?естественно!
оракл ведёт редо-логи ещё со времён оно.
это его фишка, обложенная наверное не одной сотней патенов.
оракл - отказоустойчивая субд. это так.я говорил об удобстве обслуживания сотен и тысяч рау-девайсов в кластерах и тд.
вот где у дба мозК вскепит.>И сам не мерил, но одна бабка сказала, что на ext4 базы данных по производительности приближаются к просто блочному девайсу.
приближается. в общем случае.
но есть но!
на рау-девайсах ты рулишь сам. и если рулишь правильно, то всегда будет на ~20% быстрее.
вот только это совсем уж для простеньких установок. на серьёзных сам же скажешь нафиг-нафиг мне такое ускорение.
> оракл ведёт редо-логи ещё со времён оно.
> это его фишка, обложенная наверное не одной сотней патенов.Как же тогда MS в их ESE ведет подобные по смыслу логи?
Журналы транзакция вроде бы везде в том или ином виде реализованы, где поддерживается ACID. Плюс у многих write-ahead-log есть.
Я не спорю, потому что с Ораклом мало знаком и не исключаю что там нечто особенное, хотя и сомневаюсь в этом.
Но опять же этот особенно надежный роллбэк-лог должен не лучшим способом на производительности сказываться. Возможно те же 10-20% что и при использовании ext4
Через задний проход.
> Через задний проход.А с этим никто и не спорил :). Просто более-менее характерный набор технологий все дружно передрали друг у друга.
да, но мс особенно.зыж
если вообще кто в теме - один их отказ от кластеров чего стоит! :D
(если возник вопрос при чём тут редолги - том ещё рано говорить о качестве субд ;))
> да, но мс особенно.Они были бы не MS если бы хоть что-то делали не так.
> (если возник вопрос при чём тут редолги - том ещё рано говорить
> о качестве субд ;))Честно говоря в дебри ESE особо не лазил но судя по описанию могу предположить что было что-то не так с синхронизациями транзакций или типа того.
>синхронизациями транзакцийа синхронизации транзакций идёт через таймпоинты в редологах.
зыж
просьба
>(если возник вопрос при чём тут редологи - тому ещё рано говорить о качестве субд ;))остаётся в силе ;)
>>(если возник вопрос при чём тут редологи - тому ещё рано говорить о качестве субд ;))
> остаётся в силе ;)Для начала - о качестве оракла я вроде вообще ничего не говорил. Я просто более-менее представляю себе как делается журнальная механика вообще. Но как именно оно в оракле сделано и в какую сторону развивается - вам виднее: мне этот ваш оракл никуда не сдался. Насколько я вас понял - оракл решил вынести часть функционала БД на плечи ФС, так? Попутно избавившись от повторных действий как раз.
> на рау-девайсах ты рулишь сам. и если рулишь правильно, то всегда будет
> на ~20% быстрее.Ну так оверхед от ФС отпадет окончательно. Логично же.
да.
но вырастет оверхед от количества настраиваемых девайсов по экспоненте.
> но вырастет оверхед от количества настраиваемых девайсов по экспоненте.Ну я догадываюсь насколько вы хотите админить БД в raw разделах :)
> я говорил об удобстве обслуживания сотен и тысяч рау-девайсов в кластерах и тд.
> вот где у дба мозК вскепит.У нас завелся Капитан-дба :)
> И намного быстрее их базы на Btrfs работают, чем на ZFS?Могу себе представить как в клиническом случае журнальная логика базы положенная на CoW все положит напрочь до совершенно неприличного состояния. Просто прикиньте какие действия и кто будет делать в этом случае - сами поймете в чем грабли.
а зачем его вообще спонсировать - скинтесь и спонсируйте - что то слишком много халявщиков которые поливают потом Oracle грязью.
> такое ощущение что oracle слабо финансирует разработку btrfsНу они собственно умно сделали - спонсировали аж целого архитекта. Чувак наархитектил и накодил скелетон, применив ряд вполне здравых идей от комьюнити и прочая. Спонсорство свелось аж к зарплате одного (!!!) Криса Мэйсона.
С уходом Криса Мейсона из Oracle теперь точно Oracle будет меньше финансировать разработку BTRFS (по крайней мере на размер З/П Криса):
http://www.opennet.me/opennews/art.shtml?num=34036
> разработку BTRFS (по крайней мере на размер З/П Криса):Меньше Оракела в линуксе? Хорошо! -- Больше Fusion-io в btrfs? Нуууууу......
Это который с Джобсом Apple основал? Охохо... будет гомосятский бтр.
> Это который с Джобсом Apple основал? Охохо... будет гомосятский бтр.Пусть хоть нигерский, если работает :)
>Это который с Джобсом Apple основал?Чего?
Ну подумаешь, перепутал чувак Криса Мейсона со Стивом Возняком - имена-то похожие... )))))
> Ну подумаешь, перепутал чувак Криса Мейсона со Стивом Возняком - имена-то похожие...Это ж надо столько ошибок в имени сделать :)
> разработку BTRFS (по крайней мере на размер З/П Криса):Ну если учесть что Крис срулил в другую контору - без зарплаты он явно не останется :)
> Стоит отметить, что уже сейчас данная реализация ZFS для Linux является весьма > стабильной и используется энтузиастами даже на боевых системах.Энтузиасты используют все что угодно без оглядки на стабильность. В багтрекере проекта 100+ открытых багов, включая креши, фризы и прочии радости.
> В багтрекере проекта 100+ открытых багов, включая креши, фризы и прочии радостиОткрой багтрекер ядра :)
>> В багтрекере проекта 100+ открытых багов, включая креши, фризы и прочии радости
> Открой багтрекер ядра :)Я на 2.6.32.
> Я на 2.6.32.Несомненно, это очень важные сведения для аудитории опеннета.
> В багтрекере проекта 100+ открытых багов, включая креши, фризы и прочии радости.Хотели _всю_ функциональность ZFS? Получите и распишитесь!
> Хотели _всю_ функциональность ZFS? Получите и распишитесь!Не, баги они пусть себе оставят :)
> открытых багов, включая креши, фризы и прочии радости.Ну можешь на бсдшников посмотреть как у них с ZFS. Они вообще даже баг обычно не осиливают при этом вколотить, т.к. квалификации не хватает собрать состояние системы при фризе в ФС. Зато истошно орут в списках рассылки и на форумах, чем невозбранно доставляют :)
> Зато истошно орут в списках рассылки и на форумах, чем невозбранно доставляют :)это не так страшно, как обновление убунты переустановкой.
> это не так страшно, как обновление убунты переустановкой.Не вижу чего в этом такого страшного само по себе. Быстро, результативно, доступно даже чайникам. К тому же инсталлер убунты не тупой и если ему показать разделы и не требовать форматирования - он видит что система уже была, сносит только системные диры, а юзерские не трогает. Получается чистая система без тотального дестроя юзеровых данных.
Страшно - это когда человек не хочет думать головой в принципе и думает что реинсталл - единственный вариант решения всех проблем.
Страшно - это когда wannabe-джедай не хочет переставлять систему даже поймав руткит. Думая что он умнее всех. Хотя по факту - чуть заапгрейженный дурaк при системе, не понимающий как оно работает. Это пожалуй даже страшнее по последствиям.
>> это не так страшно, как обновление убунты переустановкой.
> Не вижу чего в этом такого страшного само по себе.это естественно. гомосексуалистам естественна однополая любовь, убунтоид ничего страшного не видит в обновлении переустановкой.
> Страшно - это когда человек не хочет думать головой в принципе и
> думает что реинсталл - единственный вариант решения всех проблем.Не единственный? Ой-вэй, хто бы мог подумать!?
> Страшно - это когда wannabe-джедай не хочет переставлять систему даже поймав руткит.фантазии это круто. но давайте их пропустим.
а где iZEN? -_-
> а где iZEN? -_-Как где? Данные с ZFS восстанавливает...
Не приходилось. Как использую ZFS с версии FreeBSD 7.x, когда переходил на FreeBSD 8.x, так ни разу не приходилось восстанавливать данные с ZFS. Данные не херились. Возможно, играет свою роль самобытная культура ZFS-водства, в которой нет заумных невнятных команд и волшебных манипуляций, а всё просто и чётко.
Такие видимо данные.
Вот нжинкс не рекомендует. Лисяра восстанавливал. Айзен на винде.
> Вот нжинкс не рекомендует.вы разговариваете с нжинксом?
Нет, я читаю его реадми и хавту.
Бздишнегам видимо не понять.:D
> Нет, я читаю его реадми и хавту.
> Бздишнегам видимо не понять.:DНастоящие джедаи маны не читают. Они сперва лихо махают шашкой а только потом разбираются с проблемами.
>> Нет, я читаю его реадми и хавту.
>> Бздишнегам видимо не понять.:D
> Настоящие джедаи маны не читают. Они сперва лихо махают шашкой а только
> потом разбираются с проблемами....если есть проблемы. Кстати, ты-то маны читаешь внимательно, дай ссылочку, где nginx не рекомендуется с zfs? ы?
> ...если есть проблемы. Кстати, ты-то маны читаешь внимательно, дай ссылочку, где nginx
> не рекомендуется с zfs? ы?Да, что там nginx, вон у обычного gzip, GNU gzip, да, с zfs проблемы!
Ссылочка: http://savannah.gnu.org/forum/forum.php?forum_id=7275gzip -rf no longer compresses files more than once (e.g., replacing
FOO with FOO.gz.gz) on file systems such as ZFS where a readdir
loop that unlinks and creates files can revisit output files.
> Да, что там nginx,нет, хотелось бы именно про nginx.
> вон у обычного gzip, GNU gzip, да, с zfs проблемы!
да у него и с собственными ключами проблемы:
"gzip -d -S '' precious.gz"
* Noteworthy changes in release 1.4 (2010-01-20) [stable]** Bug fixes
gzip -d could segfault and/or clobber the stack, possibly leading to
arbitrary code execution. This affects x86_64 but not 32-bit systems.да и с 64битами тоже не фонтан... по существу-то есть что сказать?
> Нет, я читаю его реадми и хавту.
> Бздишнегам видимо не понять.:Dдействительно. они лезут в маны когда что-то не работает. а ты, видимо, из манов не вылезаешь?
> Нет, я читаю его реадми и хавту.
> Бздишнегам видимо не понять.:Dжду не первый день пруф.
> Не приходилось. Как использую ZFS с версии FreeBSD 7.x, когда переходил на
> FreeBSD 8.x, так ни разу не приходилось восстанавливать данные с ZFS.Зато ты не забыл похвастать своей ынтырпрайзной скоростью по 6Мб/сек со шпинделя. Ноутбучные диски конечно полный ахтунг, но получить с них 50Мб при линейном чтении вполне реально :)
>> Не приходилось. Как использую ZFS с версии FreeBSD 7.x, когда переходил на
>> FreeBSD 8.x, так ни разу не приходилось восстанавливать данные с ZFS.
> Зато ты не забыл похвастать своей ынтырпрайзной скоростью по 6Мб/сек со шпинделя.
> Ноутбучные диски конечно полный ахтунг, но получить с них 50Мб при
> линейном чтении вполне реально :)Нет у меня на домашнем десктопе задач, которым требуется 50 МБ/с со шпинделя. Дома мне важна тишина, а не стрёкот головок.
>Дома мне важна тишина, а не стрёкот головок.весьма забавно, да. с учётом того, что на zfs чтение - это почти всегда random access.
>>Дома мне важна тишина, а не стрёкот головок.
> весьма забавно, да. с учётом того, что на zfs чтение - это почти всегда random access.Вот именно! Ноутбучные винты, когда их много, гораздо тише перемещают головки, чем 3,5" аналоги (последние, к тому же, греются невыносимо в mATX-корпусе).
> Вот именно! Ноутбучные винты, когда их много, гораздо тише перемещают головки,Я теперь понимаю почему изена это так беспокоит. Да, если винч читает на скорости 10% от номинала - он определенно 90% гоняет головы и 10% - делает что-то полезное. Да, треск голов при этом начнет беспокоить :)
> чем 3,5" аналоги (последние, к тому же, греются невыносимо в mATX-корпусе).
Есть и мало греющиеся экземпляры, особенно low power серий на 5400 об/мин. Они обычно и головами очень тихо двигают.
> Нет у меня на домашнем десктопе задач, которым требуется 50 МБ/с со
> шпинделя. Дома мне важна тишина, а не стрёкот головок.Да суть не в том, есть или нет. 6Мб/сек со шпинделя - это уметь затормозить еще надо. Я такое видел только на 2.5" драйвах, при полностью рандомном доступе блоками в 1К с пробегом между операциями более полдиска.
> драйвах, при полностью рандомном доступе блоками в 1К с пробегом между
> операциями более полдиска.Хреново в ZFS без дефрагера на такой конфиге, походу :)
>> драйвах, при полностью рандомном доступе блоками в 1К с пробегом между
>> операциями более полдиска.
> Хреново в ZFS без дефрагера на такой конфиге, походу :)Пулы, у которых такая скорость, заполнены на 99,9% от своей ёмкости. Когда в пуле есть свободным хотя бы 15-20 ГБ скорость чтения/записи у ZFS нормальная.
Про сравнение с Btrfs говорят, что там ещё хуже ситуация обстоит: мало того, что метаданные отнимают существенную часть пространства, так при заполнении пула больше 90% скорость I/O снижается катастрофически.
>> драйвах, при полностью рандомном доступе блоками в 1К с пробегом между
>> операциями более полдиска.
> Хреново в ZFS без дефрагера на такой конфиге, походу :)"Фрагментация ZFS - мифы и реальность": http://yvoinov.blogspot.com/2010/11/zfs.html
>1. Я не включаю компрессию пулов.
>2. Во многих случаях имеет смысл ограничить кэш ZFS.
>3. Я не использую RAID-Z.
>6. Я никогда не ставлю ZFS поверх аппаратного или софтверного RAID.Это пиндец, господа.
Зфс с отключенными ВСЕМИ фичами.
Без рэйдов вообще.
Без характеристик бд (олтп? Дсс? 55% чего и от чего?)Зыж
В секции о себе можно проще — папа римский.
В коментах — о мама миа.
и да, если кто-то сравнивает с НЕ тюнингованной ufs, тот сам себе буратино.
вот тут описал.
и да, если кто-то сравнивает с НЕ тюнингованной ufs, тот сам себе буратино.
вот тут описал http://www.opennet.me/openforum/vsluhforumID3/85076.html#155
> "Фрагментация ZFS - мифы и реальность"Гражданин, ты с своими 6Мб/сек служишь просто эталоном того как делать не надо. Более того - мне очень интересно что ты будешь с этим делать. Дело в том что эти макароны на пуле сами уже нифига не рассосутся. Дефрагера нет. А сливать все данные куда-то, дестроить ФС и заново вливать их - выглядит как заявка на геморрой. Так и будешь сидеть с 6Мб/сек :)
> Гражданин, ты с своими 6Мб/сек служишь просто эталоном того как делать не
> надо. Более того - мне очень интересно что ты будешь с
> этим делать.Освобождать пул от хлама до 15-20 ГБ свободного места. Потом всё поновой, пока не надоест. :))
> Дело в том что эти макароны на пуле сами
> уже нифига не рассосутся. Дефрагера нет. А сливать все данные куда-то,
> дестроить ФС и заново вливать их - выглядит как заявка на
> геморрой. Так и будешь сидеть с 6Мб/сек :)Нету там фрагментации. Просто изначально пул забивался под завязку, файлы зазря не удалялись. Не от фрагментации скорость записи (и чтения) при многопоточных I/O такая, а от отсутствия достаточного количества свободного пространства.
> Освобождать пул от хлама до 15-20 ГБ свободного места. Потом всё поновой,
> пока не надоест. :))Прикол состоит в том что быстрее читаться то что УЖЕ в состоянии лапши раскиданой по всему диску - нифига не станет. И свободное место будет являть из себя макароны, без больших свободных пустот. В общем-то заполнять практически любую ФС на 99% это ошибка. А в случае многотомного пула и без дефрагера - еще и просто научно-технический мазохизм.
>> геморрой. Так и будешь сидеть с 6Мб/сек :)
> Нету там фрагментации.Ну да, а скорость с 50Мб/сек линейного чтения до 6Мб/сек грохнулась вовсе и не потому что винчи между фрагментами головы гоняют как угорелые :)
> Просто изначально пул забивался под завязку, файлы зазря не
> удалялись. Не от фрагментации скорость записи (и чтения) при многопоточных I/O
> такая, а от отсутствия достаточного количества свободного пространства.Да ты лол. А ты представляешь себе что происходит при малом количестве свободного пространства? Аллокатор уже не может найти свободный непрерывный блок когда приперло записать большой кусок. Поэтому он раскидывает записываемое не как хотелось, а уж как выйдет. Ну то-есть раскидав по останкам свободного места. Когда ты сотрешь такой файл, место от него конечно освободится. В виде все тех же макаронов распиханых по всему диску, ага. И когда аллокатору понадобится свободное место - он будет втискиваться в эти же макароны. Чем сильнее заполнен том и дольше он в таком состоянии был - тем сильнее идет фрагментация в плане увеличения числа фрагментов и усугубления ситуации :). Ну вот потому скорость и падает во столько раз: вместо того чтобы прочитать куски рядом, приходится их судорожно выколупывать по всему диску. А CoW логика с ее склонностью к фрагментации в таком режиме должна еще веселее чем обычные ФС зашиваться. Судя по тому что у тебя за скорости - ты вполне с этим справился.
> Нет у меня на домашнем десктопе задач, которым требуется 50 МБ/с со шпинделя."и пусть весь мир подождет!". ИМХО, опубликуй лучше ман по сбору raidz из флоппиков, это даже веселее по параметрам получится :)
> Дома мне важна тишина, а не стрёкот головок.
Так с этим никто и не спорит. Вот только скорость в 6Мб/сек намекает на то что головы постоянно летают туда-сюда. Если бы этого не было - было бы 50Мб/сек со шпинделя.
> а где iZEN? -_-Накаркали :)
А можно чуточку оффтопа? Кто-нибудь на CentOS 6.2 юзал BTRFS? Юзабельно, или надо патчить?
последнее ванильное ядро (вообще-то с 3.3.5 и выше). (или из оракл унбрикэбл линух)
последние бтрфс-утилс. (или из оракл унбрикэбл линух)
с компрессией (особенно на критичных данных) лучше не заморачиваться вообще пока. ибо зависит от железа.вот так - юзабельно вполне.