Опубликован (https://clusterhq.com/blog/state-zfs-on-linux/) обзор текущего состояния разработки проекта ZFSonLinux (http://zfsonlinux.org/), в рамках которого развивается реализации файловой системы ZFS, оформленная в виде модуля для ядра Linux. Формально вышедшая в марте прошлого года версия 0.6.1 была объявлена первым стабильным выпуском ZFSonLinux, тем не менее разработчики получают много вопросов о том, годов ли проект для промышленного применения. Ричард Яо (Richard Yao), занимающий второе место среди разработчиков по число добавленных изменений, подробно обосновал, почему он считает ZFSonLinux полностью стабильным и полнофункциональным продуктом, готовым для повсеместного применения.
Текущий уровень стабильности ZFSonLinux на 64-разрядных системах оценивается (https://clusterhq.com/blog/zfs-on-linux-runtime-stability/) как соизмеримый с другими файловыми системами для Linux, а функциональность близка к возможностям других реализаций ZFS, что делает ZFSonLinux полноценным конкурентом (https://clusterhq.com/blog/zfs-suitable-replacement-file-sys.../) таким ФС, как ext4, XFS, JFS и Btrfs.
ZFSonLinux предоставляет (https://clusterhq.com/blog/file-systems-data-loss-zfs/) надёжную гарантию обеспечения целостности данных и значительно превосходит по средствам сохранения целостности другие ФС для постоянно подключенных накопителей. Например, для защиты от сбоев во время записи и внезапных аппаратных проблем благодаря для применения изменений используется двухуровневая система транзакций, гарантирующая нахождение данных в согласованном виде. Для отслеживания повреждений на этапе чтения применяется контроль целостности с использованием 256-разрядных контрольных сумм.
Стабильность кодовой базы ZFSonLinux оценивается (https://clusterhq.com/blog/zfs-on-linux-runtime-stability/) как сопоставимая с другими ФС для Linux, что достигается тщательным рецензированием кода, проведением статического анализа и тестирования. Достижению паритета в функциональности с реализациями ZFS для FreeBSD и Illumos способствует проект OpenZFS (http://www.opennet.me/opennews/art.shtml?num=37938), в рамках которого разработчики различных реализаций ZFS объединили усилия по развитию ZFS, обмена разработками и обеспечению переносимости. В настоящее время отмечается 18 возможностей ZFS из Illumos, которые пока не перенесены в ZFSonLinux.
Из недоработок отмечается необходимость ручного контроля синхронности пользовательского инструментария и кода на стороне ядра, проблемы с размещением в zvol раздела подкачки, проблемы со стабильностью на 32-разрядных системах, недостаточно полная интеграция с загрузчиками, отсутствие средств для автоматизации антивирусной проверки новых данных через ClamAV, отсутствие поддержки iSCSI, Zerocopy NFS через RDMA (Remote Direct Memory Access). В ближайшем выпуске 0.6.4 ожидается поддержка AIO, сжатия метаданных с использованием алгоритма LZ4, расширяемых наборов данных, закладок (ZFS bookmark), встраивания содержимого мелких файлов в dnodes, задание ограничений для снапшотов.
В рамках ZFSonLinux подготовлена реализация компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Реализованная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава Illumos и FreeBSD. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo, Sabayon Linux и AltLinux. Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.
URL: https://clusterhq.com/blog/state-zfs-on-linux/
Новость: http://www.opennet.me/opennews/art.shtml?num=40566
Увы, но будущее за Btrfs...
Поскольку "...что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра Linux..."
> Поскольку "...что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра
> Linux..."Это нормальных людей не волнует. А учитывая какой крап btrfs, как раз таки будущее на ZFS и только.
бтэр рулит и педалит не требуя огромных ресурсов памяти и проца.
> бтэр рулит и педалит не требуя огромных ресурсов памяти и проца.А также имеет потенциал для более шустрой работы. Экстенты - изначально есть, при том не обрубочные а нормальные. Наиболее тормозные места - изрядно оптимизнули в последних ядрах. В последних ядрах на глаз btrfs вообще сложно от ext4 отличить при обычном десктопном юзеже. У CoW разумеется есть слабые места. Как впрочем и у любых иных подходов. В целом симпатичненько так работает. Я его от EXT4 правда на глаз при сильном желании отличу, но не по скорости работы а по иному миганию индикатора HDD :)
Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга. Ну, когда для виртуального тома места не хватает в полупустом пуле... Это так?
Нет.
Потому что там нет таких понятий как "виртуальный том" и "полупустой пул".
В какой версии? У меня на 3.13 при работе графита - забивалось все место под данные, под метаданные ничего не оставалось. При этом места дофига (больше двух третей) свободно, но так как все зарезервировано под данные - файлы уже не записать.
> В какой версии? У меня на 3.13 при работе графита - забивалось
> все место под данные, под метаданные ничего не оставалось.Это не вы тот чудак который базу с активной записью на CoW положил? Я расписал более-менее причины в другом треде, если это вы - http://www.opennet.me/openforum/vsluhforumID3/98299.html#591 - правда мне все-равно не понятно почему GC не успевает чистить. База настолько убер-активная?
> При этом места дофига (больше двух третей) свободно, но так как все зарезервировано
> под данные - файлы уже не записать.Там нет никакого "резерва под данные". Но сделать ФС без единого файла на которой нет места - можно. Достаточно сделать хотя-бы 1 снапшот и отрастить дельту от него побольше. В результате место уйдет на хранение снапшотов и отличий текущего вида от снапшотов :).
Да, "лабиринт отражений" требует неких ресурсов на свое существование - разные состояния не берутся из ниоткуда и хранение состояний и отличий очень даже занимает место. Эти же грабли характерны для виртуалок со снапшотами - их CoW based диски при безбашенном использовани могут достигнуть терабайтных величин при свободном месте порядка нескольких гигабайтов. Такая вот особенность технологий со множественными состояниями. Btrfs еще и на автомате временные снапшоты лепит, а потом убивает GCом, если не зафиксировать на постоянно. По поводу чего базы с множеством мелких записей такой механике не друг. Но есть chattr +C, позволяющий это пролечить (читайте маны, есть особенности).
Ничего что запись файлов графита - этот тот самый случай, где cow мог бы проявить себя с лучшей стороны? Не говоря уже о том, что без Cow - BTRFS вообще все свои навороты теряет (контрольные суммы, компрессия...). Кстати, мне удалось добиться от BTRFS работы с графитом, отформатировал в mixed mode. Но там другие засады.
> Ничего что запись файлов графита - этот тот самый случай, где cow
> мог бы проявить себя с лучшей стороны?CoW склонен к фрагментации, если ворклоад выглядит как множество частых мелких записей в файлы, особенно если файл патчится in place и/или часто дописывается. Работает CoW так. Любое изменение = выносок в сторону, старые данные не разрушаются и по прежнему доступны, что и позволяет просто и естественно ворочать множественными состояниями. Если выносков много, последовательное чтение будет тормозить. Куча выносков размазанных по всему диску - не айс, особенно на механике. Фрагментация подскочит до небес, а GC будет весьма неспешно работать.
Наверное в клиническом случае может так выйти что GC вообще не будет успевать вытирать устаревший крап и место закончится. Но в этом случае проще CoW для проблемного файла или диры отключить, раз ворклоад настолько недружественный и интенсивный. Или вы просто положили btrfs на диск мизерного размера, на что он не оптимизирован по дефолту. Я не в курсе что за графит такой, но у вас скорее всего что-то из того что в https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_cl...
> Не говоря уже о том, что без Cow - BTRFS вообще все свои навороты теряет
> (контрольные суммы, компрессия...).Базы данных и диски VM обычно сами реализуют некислые схемы журналирования и т.п.. Относится ли это к этому вашему графиту - я честно говоря не знаю.
> Кстати, мне удалось добиться от BTRFS работы с графитом, отформатировал в mixed mode.
А у вас что, совсем мелкий стораж? (я спрашивал про размер, но ответа не увидел). Это ж обычно актуально для сторажей в считанные гигабайты, IIRC.
> Но там другие засады.
Например какие? Я так сходу знаю 1: любители btrfs должны любить свежие ядра. Свежие - это последняя версия (по мнению kernel.org). Даже в 3.17 например будет починен 1 редкий но меткий баг - зависон при активной работе с компрессоваными данными, посажен в районе 3.14, при переводе фоновых работ на ядерные очереди с местечкового велосипеда.
На фрагментацию как раз покласть - графиту нужнее успеть записать все метрики. Которые пишутся каждая в свой файл (что без CoW-а и журнала - приводит к случайному дерганью дисков постоянно). Whisper никакого журнала не делает, так что идеальная задача для CoW. А Вы ее отключать советуете... Умно!Размер - от нескольких десятков мегабайт (в сжатом виде, для уменьшения дисковых операций), до пары террабайт. Да, приходится в mixed mode, иначе смерть через несколько дней от этого самого no space left.
> Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга. Ну, когда
> для виртуального тома места не хватает в полупустом пуле... Это так?Да, так же, как на твоей ZFS "в некоторых случаях" требуется $скока-скока-? гигабайт для _установки.
> Да, так же, как на твоей ZFS "в некоторых случаях" требуется $скока-скока-?
> гигабайт для _установки.Для функционирования ZFS нужно от четырёх гигабайт ОЗУ и 64-битная ОС.
Все настраивается, ZFS очень компромиссная ФС. В отличии от многих радикальных.
> Все настраивается, ZFS очень компромиссная ФС. В отличии от многих радикальных.Да, все настраивается, только tradeoff - выбор между дикими тормозами странной механики и конским потреблением памяти.
>> Все настраивается, ZFS очень компромиссная ФС. В отличии от многих радикальных.
> Да, все настраивается, только tradeoff - выбор между дикими тормозами странной механики
> и конским потреблением памяти.Может ты успокоишься уже? Ты в этой теме столько наболтал, что собрав твои сообщения в общем четко понятно, что ты ничерта в ZFS не понимаешь. Однажды, случайно, установив ZFS, натыкав галочки в GUI по умолчанию, получив хлам сейчас сидишь и гадишь в сторону ZFS. А ZFS не для лохов. Там понимать надо, что ты делаешь и для чего.
> твои сообщения в общем четко понятно, что ты ничерта в ZFS
> не понимаешь. Однажды, случайно, установив ZFS, натыкав галочки в GUI по
> умолчанию, получив хлам сейчас сидишь и гадишь в сторону ZFS.Прикольные аргументы с попыткой выдать желаемое за действительное. Только это не так. Я посмотрел на сорцы + устройство дисковых структур. На мнения тех кто занимается разработкой и изучением файловых систем. На коменты разработчиков. В сумме я подофигел от увиденного. Потому что видим мы огромный сложный пепелац с довольно странным устройством, где даже сами разработчики в половине мест не могут сказать "а зачем это было сделано вот так?". А половина вполне имеющих место быть проблем - просто заметены под ковер саночными маркетологами. Подленько и цинично.
> А ZFS не для лохов.
Да, отправь СМСку с текстом "Не лох!!!" на короткий номер. Ведь чем больше смс ты отправишь - тем больше ты не лох.
> Там понимать надо, что ты делаешь и для чего.
Вот я и понял что заниматься костылированием и вытягиванием такого дизайна ФС меня что-то не прельщает.
п%ж и провокация
http://docs.oracle.com/cd/E26502_01/html/E29007/gbgxg.html#s...http://download.oracle.com/docs/cd/E19253-01/820-0836/820-08...
"Требования и рекомендации по программному
обеспечению и оборудованию ZFS
Убедитесь в том, что перед использованием программного обеспечения ZFS были
выполнены следующие требования и рекомендации по программному обеспечению и
оборудованию:
■ Система SPARC® или x86 под управлением выпуска Solaris 10 6/06 или более позднего.
■ Минимальная емкость диска – 128 МБ. Минимальный размер дискового
пространства для пула устройств хранения данных составляет около 64 МБ.
■ В настоящее время минимальный объем памяти, рекомендуемый для установки
системы Solaris, составляет 768 МБ. Однако для обеспечения высокой
производительности ZFS рекомендуется по крайней мере 1 ГБ памяти или более.
■ При создании зеркальной настройки дисков рекомендуется использовать несколько
контроллеров."
>[оверквотинг удален]
> оборудованию:
> ■ Система SPARC® или x86 под управлением выпуска Solaris 10 6/06 или
> более позднего.
> ■ Минимальная емкость диска – 128 МБ. Минимальный размер дискового
> пространства для пула устройств хранения данных составляет около 64 МБ.
> ■ В настоящее время минимальный объем памяти, рекомендуемый для установки
> системы Solaris, составляет 768 МБ. Однако для обеспечения высокой
> производительности ZFS рекомендуется по крайней мере 1 ГБ памяти или более.
> ■ При создании зеркальной настройки дисков рекомендуется использовать несколько
> контроллеров."Да? А может Ораклу надо продать подороже?
Беда... У меня на файлсервере (софтрейд, бакула, домен и еще че-то) 1ГБ ОЗУ и 32битная ОС из которых занято может 200МБ в активном режиме. Если захочу просто какой-нить дедупликации по ночам и версионности, то не потянет чтоль?
> Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга.В некоторых - требует.
> Ну, когда для виртуального тома
В btrfs нет таких понятий.
> места не хватает в полупустом пуле... Это так?
Нет, не так. Ты опять где-то начитался какой-то бредятины и нифига не понялю
>> Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга.
> В некоторых - требует.Конкретизируй, в каких?
>> Ну, когда для виртуального тома
> В btrfs нет таких понятий.Подтома, subvolume.
>> места не хватает в полупустом пуле... Это так?
Места для новых метаданных не было зарезервировано - нельзя создать подтом.
> Нет, не так. Ты опять где-то начитался какой-то бредятины и нифига не
> понялюНу а зачем ты в теме про ZFS пишешь про Btrfs?
> Конкретизируй, в каких?Основное применение - если добавили в пул новый диск и хочется снести на него часть нагрузки. Ну еще для воссоздания копии raid-1 после изъятия сдохшего диска. Это штатные применения. Еще - как побочный эффект может освободить некоторый объем свободного места, но это костыль и обычно имеет смысл в кривых случаях и не должно требоваться в нормальной ситуации.
Возможен также реверсный балансу процесс: можно запросить изъятие диска из пула, при этом будет проход по back references - блоки с указанного диска будут убраны на другие диски, если там есть достаточно места. После этого диск не будет содержать ни 1 блока данных и метаданных и его можно безболезненно изъять из пула. Свободное место доступное btrfs в пуле сократится на размер изъятого диска, что логично. А в ZFS штатно backrefs нет и поэтому удвинуть "вот эти блоки с вот этого диска" простыми и очевидными методами - вообще опаньки, т.к. нет простого метода понять к кому они относились и пометить перемещение, чтобы блоки искали в новом месте. Я так понимаю что человеческого изъятия диска из пула в ZFS до сих пор нет? (не очень понимаю как это можно культурно делать при дисковой механике где это заранее не предусмотрели)
Вообще, https://btrfs.wiki.kernel.org/index.php/FAQ#What_does_.22bal...
Там же рядом рассказано почему все так сложно с свободным местом ;). Даже сами разработчики согласны с тем что это не круто, но - вы готовы предложить алгоритм, готовый столкнуться с пообъектным RAID-ом? Заранее неизвестно какой RAID для какого объекта могут попросить, что доставляет.
> Подтома, subvolume.
А, ты про них. Там скорее проблема в мелком стораже - дефолты btrfs не заточены на всякие карты памяти в пару гигз. Для любителей утонченных извращений сделали mixed mode который не страдает от гранулярности выделения чанков на данные/метаданные. Но все это актуально для мизерных носителей, когда гранулярность аллокации чанков сравнима с размером носителя. Актуально при размерах всей ФС порядка несколько Гб. На более крупных ФС оно по идее и без этого должно быть в более-менее нормальном состоянии с точностью до крох, которые мало что решают.
> Места для новых метаданных не было зарезервировано - нельзя создать подтом.
Ты думается не о том, а о выделении чанков на данные/метаданные, на мелком носителе гранулярность выделения может быть сравнима с размером носителя и может выйти дурная ситуация когда все чанки с данными или метаданными заняты, а противоположных типов чанков не хватило и вроде как места еще немного есть, но создать файл не выйдет из-за невозможности записать данные или метаданные. Но это актуально только для мелких носителей. Для больших носителей (на что btrfs в основном и заточен) - неточность в стыковке размера данных и метаданных будет в пределах погрешности.
А подтома в btrfs штука своеобразная. Это некая административная единица, подддерево которое может иметь ряд настроек отличных от остальных и ведет себя как отдельная независимая точка входа в новую ФС, по типу "/" в плане следования иерархии, снапшотирования и прочее. Но все эти "новые ФС" шарят на все и всяя пространство единого глобального пула свободного места.
> Ну а зачем ты в теме про ZFS пишешь про Btrfs?
Это не я начал. А пишу потому что анноит читать тормозизмы и/или явную дезу.
Не знаю что он там рулит и педалит, у него элементарные проблемы со стабильностью (на нестабильно работающих/сыплющихся дисках несколько раз получал невосстанавливаемый волюм).
На реальных системах с высоким в/в его просто невозможно использовать. И это после 7-и лет разработки...
Будущее за exFat :-)
Боинги в пролете - их зарулят цессны, по любому.
zfs под линь пока что такой же крап
> таки будущее на ZFS и только.А как насчет
1) Полноценных экстентов, а не обрубков?
2) Что там с управлением памятью? Как насчет интеграции управления кэшом с работой памятью в ядре?
3) А как насчет возможности изъять носитель из пула? Там уже стало можно удвигать данные с диска по человечески с целью его изъятия?
4) А дефрагер в CoW по прежнему "не нyжен", как вещали саночные врунишки-маркетологи?Бонусом ZFS еще и в ядре по дефолту отсутствует, так что ни о каком "полноценным конкурентом таким ФС, как ext4, XFS, JFS и Btrfs" речь не идет в принципе! На секундочку, установку на XFS, Btrfs, ext4 и прочее - можно прямо при инсталляции дистра выбрать. Но с ZFS жтот номер в большинстве дистров не пройдет.
>Увы, но будущее за Btrfs...Сколько у тебя свободного места на диске? Ах, btrfs не может это показать...
> Сколько у тебя свободного места на диске? Ах, btrfs не может это показать...Что достаточно логично для CoW с автоснапшотами, в котором свободное место - понятие относительное. Потому что объем свободного места зависит еще и от снапшотов и того готовы ли вы ждать пока например GC попашет. Можно запросто сделать так что на ФС без единого файла не будет места - все займут прошлые состояния и отличие от них. При этом вы не сможете ничего записывать в текущее состояние. Зато у вас будет 100500 прошлых состояний на выбор по которым можно шариться. Это не баг и не фича. Просто особенность технологии.
нехилая такая фича. обычный юзер не может просто так взять и узнать, поместится у него фильм на диске или нет. я б на месте юзера закопал бы такую систему вместе со всеми её такими небагами
Обычные юзеры сидят на ext4 и не пищат.
> нехилая такая фича. обычный юзер не может просто так взять и узнать,
> поместится у него фильм на диске или нет.Если у тебя использование ФС завалилось в такой сценарий - держись от CoW подальше, ибо если ты CoW забьешь на 100% - там будет столько фрагментов-выносков распиханых в вермишель по всему диску, что потом даже дефрагер будет неделю эту жесть фиксить. Это отличный прострел своей пятки. Так что если у тебя такие сомнения вообще есть - лучше не юзай CoW-based FS для твоего же блага.
Тут один кадр aka iZEN завалил свой мегапул из 3 дисков с ZFS до состояния, когда скорость 20 мег на пул из 3 винчей. То-есть, ~6-7Мб/сек на шпиндель. При линейной скорости чтения ну уж никак не менее 50, даже у самого ушатанного ноутбучного винча. И это на более-менее большом линейном файле, он как раз на примере мувика показывал, IIRC. А вот пролечить такую ...опу в ZFS - а это вообще как? Удвинуть все данные руками куда-то еще на другие ФС, поудалять данные и снапшоты, потом заново перекопировать? Или просто пересобрать пул с ноля, что примерно одно и то же по смыслу? Ну да, очень удобно, блин.
> я б на месте юзера закoпал бы такую систему вместе со всеми её такими небагами
Забивать даже классическую файлуху близко к 100% занятие субоптимальное, а CoW - субоптимальное вдвойне. А так df тебе какую-то цифирь вернет. Как и сисколы. Только эта цифирь - не то чтобы окончательная. Потому что попахав GC'ом - можно отобрать еще места. Только заранее неизвестно сколько - для этого GC должен пойти и посмотреть что можно отжать. Это долго. На каждый запрос "сколько места" не подергаешь.
А на месте юзера - да закaпывай. Только вот если я случайно диру на btrfs снесу по ошибке, или того хуже, перезапишу вон тот файл старой версией, например - ну, в btrfs я достану снапшот и переиграю. А на обычной ФС - будешь драть волосы на всех частях тела с досады.
Тормознутость ZFS тогда пролечилась несколькими командами отключающими свойство дедупликации у всех ФС этого пула. Почему ты это старательно замалчиваешь, я не возьму в толк.Другая опа случилась при апгрейде ZFS пулов после обновления системы: просто они были заполнены на 99% и не хватило места для новых метаданных - ФС перешли в состояние read only. Но, опять же, и эта проблема решилась удалением некритичных файлов.
> Тормознутость ZFS тогда пролечилась несколькими командами отключающими свойство
> дедупликации у всех ФС этого пула.1) Не понимаю как дедупликация может влиять на скорость чтения. Ну запись еще понятно, но у тебя ж вроде и чтение было в такой же лузе? Чтобы осознать насколько это луза: ARMовская платка с гигагерцевым процом и гигом оперативы с EXT4 читает с одного ноутбучного диска 90Мб/сек. Ну правда диск терабайтник и 7200RPM (да, такое нынче в 2.5" упаковывают).
> Почему ты это старательно замалчиваешь, я не возьму в толк.
Не помню чтобы ты показывал новые данные.
> Другая опа случилась при апгрейде ZFS пулов после обновления системы: просто они
> были заполнены на 99% и не хватило места для новых метаданныхНу ты напрасно так с CoW - он тебе выносков нагородит и файлы по мере дозаписи/перезаписи превратятся в вермишель, равномерно размазанную по всему диску, на механике это будет означать отвратную скорость последовательного чтения. При том у ZFS дефрагера IIRC вообще совсем нет и undo этого безобразия можно сделать только стерев большинство файлов в надежде что свободное место придет в менее вермишельный вид. Только для эффективности этого деяния надо почти все файлы снести, что по смыслу близко к пересозданию пула с ноля.
> - ФС перешли в состояние read only. Но, опять же, и
> эта проблема решилась удалением некритичных файлов.Да проблема CoW не в том, а в выносках с отличиями от предыдущего варианта. Если с местом душняк - даже обычная ФС будет распихивать файлы не "как лучше" а "как получится", постепенно превращаясь в мелкую вермишель. А CoW из-за своей природы количество фрагментов будет плодить еще быстрее. Саночники судя по их FAQам явно в курсе проблемы, раз советуют добавлять диск в пул при занятости в 80%. Что забавнее - они кажется не имеют плана действий на случай если это все-таки случилось. А в долговременном плане количество фрагментов все-таки будет увеличиваться и скорость работы ФС может деградировать.
> Забивать даже классическую файлуху близко к 100% занятие субоптимальное, а CoW -
> субоптимальное вдвойне. А так df тебе какую-то цифирь вернет. Как и
> сисколы. Только эта цифирь - не то чтобы окончательная. Потому что
> попахав GC'ом - можно отобрать еще места. Только заранее неизвестно сколько
> - для этого GC должен пойти и посмотреть что можно отжать.
> Это долго. На каждый запрос "сколько места" не подергаешь.Ну и бредятина эта ваша Btrfs с невнятным GC, который ещё нужно ждать, пока разрешится от родов свободного места. df на ZFS амнезией не страдает.
> Ну и бредятина эта ваша Btrfs с невнятным GC, который ещё
> нужно ждать, пока разрешится от родов свободного места.Основная неопределенность в нормальных случаях даже не от этого, а от того что RAID может быть пообъектно. И заранее неизвестно какой RAID будет запрошен для вон того нового объекта.
При этом с логической точки зрения не совсем понятно что надо показать как "доступное место вообще". Можно показать суммарное свободное место по девайсам, но если ты например зеркалишь - тогда влезет в 2 раза меньше. И даже не в 2. А "когда у файловой системы закончатся возможности класть блоки на 2 физически разных девайса". Круть и гибкость в управлении RAIDовыми уровнями имеет некие странноватые tradeoff.
Еще сжатие есть. Заранее неизвестно насколько твои данные сожмутся. Поэтому если ты думаешь что вон та цифирь в ФС со сжатием - окончательная величина, ХРЕН ТЕБЕ, золотая рыбка.
> df на ZFS амнезией не страдает.
Ну так df на btrfs тоже нечто покажет. Просто это нечто - сферическое и в вакууме. И зависит от многих "если". Что интереснее, это можно сказать и про иные ФС, например, свободное место - очень условная величина, если ФС умеет сжатие. В том плане что сколько по факту влезет != тому что эта цифирь показывает.
> нехилая такая фича. обычный юзер не может просто так взять и узнать, поместится у него фильм на диске или нет. я б на месте юзера закопал бы такую систему вместе со всеми её такими небагамиКгхм. Я, вообще говоря, в возможностях btrfs и zsh не шарю вообще. Но Вы, очевидно, напрасно считаете, будто узнать остаток места на диске возможно на обычных файловых системах типа ext.
Это же классика системного администрирования: спросить у собеседуемого, почему вывод команд du и df отличается...
Здравствуйте админ локалхоста. btrfs filesystem df /
> Здравствуйте админ локалхоста. btrfs filesystem df /Он наверное про то что показывает обычный df и соотв. сисколы. Ну... ээ... понимаете, там же тоже надо показывать что-то. И там нет места для вербозного показа что и где - ожидается какая-то одна цифирь.
> Увы, но будущее за Btrfs...На линуксе, несомненно — да. Непонятно зачем было вообще тащить ZFS в линукс.
> На линуксе, несомненно — да. Непонятно зачем было вообще тащить ZFS в линукс.Некоторые хотят. Ну и пусть себе тащат, жалко чтоли?
> Увы, но будущее за Btrfs...
> Поскольку "...что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра
> Linux..."Школьникам опять невдомек, что стоимость владения хранилищем для бизнеса главное? И там производительность просто один из углов внедрения..
> Школьникам опять невдомек,НеШкольники (tm) атакуют :)
если вы сидели даже не на ехт4, то какого "гуя" ломанулись вообще непонятно на что...
> вышедшая в марте прошлого года версия 0.6.1
> подробно обосновал, почему он считает ZFSonLinux полностью стабильным и полнофункциональным продуктомБугога, врать то меньше надо, товарисч китайоза. все мы знаем что zfs - тормозной глючный хлам.
> все мы знаемОтучаемся говорить за всех.
> ... все мы знаем
> ... за всех.Рекурсия однако.
> Бугога, врать то меньше надо, товарисч китайоза. все мы знаем что zfs
> - тормозной глючный хлам.Не скажу за ZFS, а btrfs под более-менее обычный юзеж на накопителях нормального размера - вполне пригоден вроде. За enterprise grade стабильность под хайлоадом не поручусь, но на десктопах - just works вроде. Из очевидных методов свалить - возиться с RAID5/6, но про это честно предупредили.
>> Бугога, врать то меньше надо, товарисч китайоза. все мы знаем что zfs
>> - тормозной глючный хлам.
> Не скажу за ZFS, а btrfs под более-менее обычный юзеж на накопителях
> нормального размера - вполне пригоден вроде. За enterprise grade стабильность под
> хайлоадом не поручусь, но на десктопах - just works вроде. Из
> очевидных методов свалить - возиться с RAID5/6, но про это честно
> предупредили.Как раз raid-5/6 и есть самое интересное для не-enterprise, да и им может пригодится raid-50/60 (5/6+0). Аналога raidz3 нет, насколько я знаю.
Нельзя создать raid1, в котором больше 2-х дисков:
RAID-1 is defined currently as "2 copies of all the data on different devices".
ZFS умеет нормально:
zpool create tank mirror /dev/sda /dev/sdb /dev/sdcДа и все остальное работает только если сильно не насиловать, половина фич экспериментальная, да и сама btrfs тоже.
> Как раз raid-5/6 и есть самое интересное для не-enterprise, да и им
> может пригодится raid-50/60 (5/6+0).Ну вы так универсально и за всех расписываетесь, что просто любо-дорого смотреть. Ну если самое интересное - тогда навались на кодинг и тестирование, чтоли.
> Аналога raidz3 нет, насколько я знаю.
Нет. Однако на уровне механики файлухи есть очень интересная вещь: оно может кроить уровни RAID пообъектно. Оно уже умеет хранить данные и метаданные с разными уровнями. А сам по себе дизайн подразумевает возможность это делать по разному для разных файлов.
В идеале это будет как-то так: для файла запрашивается некий уровень RAID и если его в принципе можно изобразить (==достаточно свободного места для этого уровня RAID на достаточном кол-ве устройств) - файлуха идет и делает это. При этом всякое пoрeво можно разложить в stripe для скорости из соображений "да фиг с ним, перекачаю", а рабочие документы - хоть с пятикратным дублированием, если они небольшие и места не жалко. Ну да, пока еще не все из этого в полном объеме реализовано. Но такая возможность изначально сделанная на уровне механики ФС очень радует. Хорошо когда архитект хочет летать высоко, хоть это и сложно.
> Нельзя создать raid1, в котором больше 2-х дисков:
raid1 нельзя, но с технической точки зрения я не вижу чему противоречит зеркало из N копий вместо частного случая из 2 копий. Ну да, это не будет называться raid1 с формальной точки зрения.
> ZFS умеет нормально:
Btrfs оперирует в намного более крутом контексте на самом деле. Есть устройства. Есть свободное место на них. А далее нужный уровень RAID лепится для конкретного объекта, если ситуация это вообще технически позволяет. Это разумеется создаст и баги и фичи, например, типа необходимости как-то контролировать в явном виде - а удалось ли вон тому объекту сделать RAID нужного уровня при текущей ситуации. Но в целом это огроменный шаг вперед vs мышления заклиненого на фиксированной аллокации дисков с жестким зашиванием уровня RAID, после чего переконфигурирование стоража превращается в филиал ада.
> Да и все остальное работает только если сильно не насиловать,
Для обычного десктопа например - выше крыши. Мордокнига вон рискует здоровьем на серверах опробывать. Баги есть, но их удавят. А мышление этого архитекта мне нравится. Масштабно мыслит, не боится использовать подходы отличные от классики, хоть это и вызывает у некоторых отвалбашки.
> половина фич экспериментальная, да и сама btrfs тоже.
Ну, я ей вполне практически пользуюсь в ряде не очень ответственных применений. Вроде работает. А так - я могу загнать в штопор любую ФС. Только зачем мне себе пятки простреливать?
>> Как раз raid-5/6 и есть самое интересное для не-enterprise, да и им
>> может пригодится raid-50/60 (5/6+0).
> Ну вы так универсально и за всех расписываетесь, что просто любо-дорого смотреть.
> Ну если самое интересное - тогда навались на кодинг и тестирование,
> чтоли.Пока что btrfs позволяет stripe и raid1, при ограниченном бюджете и не принимая в расчет сервера с кучей дисков, raid5 на 3-4 диска это самое оно, если вы хотите обезопасить свои файлы, но не покупать кучу дисков для зеркал.
А про кодинг и тестирование - уже есть ZFS которая прекрасно работает, зачем?>[оверквотинг удален]
> В идеале это будет как-то так: для файла запрашивается некий уровень RAID
> и если его в принципе можно изобразить (==достаточно свободного места для
> этого уровня RAID на достаточном кол-ве устройств) - файлуха идет и
> делает это. При этом всякое пoрeво можно разложить в stripe для
> скорости из соображений "да фиг с ним, перекачаю", а рабочие документы
> - хоть с пятикратным дублированием, если они небольшие и места не
> жалко. Ну да, пока еще не все из этого в полном
> объеме реализовано. Но такая возможность изначально сделанная на уровне механики ФС
> очень радует. Хорошо когда архитект хочет летать высоко, хоть это и
> сложно.Несомненно фича интересная, но вызывает много вопросов, например насколько хорошо оно будет балансировать данные между дисками, при наличии множества разных уровней raid и не будет ли кучи потерянного места. А также как оно себя поведет, если например у вас в пуле raid0 диск накрылся, но пару файлов вы как raid1 хранили - их конечно можно будет fsck выковырять я так понимаю..
>> Нельзя создать raid1, в котором больше 2-х дисков:
> raid1 нельзя, но с технической точки зрения я не вижу чему противоречит
> зеркало из N копий вместо частного случая из 2 копий. Ну
> да, это не будет называться raid1 с формальной точки зрения.Вот и я не понимаю почему такую элементарную вещь btrfs не может, а кому-то данные очень важны...
> Btrfs оперирует в намного более крутом контексте на самом деле. Есть устройства.
> Есть свободное место на них. А далее нужный уровень RAID лепится
> для конкретного объекта, если ситуация это вообще технически позволяет. Это разумеется
> создаст и баги и фичи, например, типа необходимости как-то контролировать в
> явном виде - а удалось ли вон тому объекту сделать RAID
> нужного уровня при текущей ситуации. Но в целом это огроменный шаг
> вперед vs мышления заклиненого на фиксированной аллокации дисков с жестким зашиванием
> уровня RAID, после чего переконфигурирование стоража превращается в филиал ада.Можно также спорить, что управление мешаниной из различных уровней raid тоже филиал ада.
Хотя согласен, что при наличии всего двух хардов, наверно удобно документы хранить в raid1, а порно в raid0 на тех же дисках.>> Да и все остальное работает только если сильно не насиловать,
> Для обычного десктопа например - выше крыши.Я знаю многих, у кого на десктопе raid5.
> Мордокнига вон рискует здоровьем на серверах опробывать.
Google тоже использует ext4 без журнала, потому что им проще тупо диск заменить если с ним что-то не так и засинхронизировать с другого сервера.
ZFSonLinux в IBM Sequoia используется например.>> половина фич экспериментальная, да и сама btrfs тоже.
> Ну, я ей вполне практически пользуюсь в ряде не очень ответственных применений.В том то и дело, что zfs вполне можно доверить данные, поэтому статья и говорит что оно production ready с небольшими оговорками.
У ZFS тоже есть недостатки, в частности домашних пользователей печалит невозможность на данный момент удалить диск из пула (в проекте) или добавит диск в vdev (Т.е. вместо raidz на 3 диска сделать raidz на 4 и сделать перестройку массива. Добавить vdev к страйпу можно и сейчас и также можно заменить все диски в vdev на больший объем и сделать ресайз).
С памятью по большей части проблемы надуманы и в основном относятся к ONLINE! dedup, который почти наверняка у BTRFS будет жрать столько же памяти, это почти неизбежно.Но в целом на данный момент ZFS гораздо более надежна и функциональна по сравнению с BTRFS для большинства применений, кроме самых базовых вроде fs на одном диске/stripe/mirror.
> Пока что btrfs позволяет stripe и raid1,А также raid5/6 если вы ощущаете себя реальным камикадзе. Но оно пока сырое и не для продакшна.
А вообще, теоретически btrfs может на ходу разложить "вот этот файл" в "вон такую схему RAID". При условии что свободное место на достаточном количестве девайсов это позволит. Это уход от фиксированных уровней RAID, жестко привязанных к дискам и их количеству. Совсем иной взгляд на то как можно делать RAID. Есть девайсы и свободное место на них. Можно для "вот этого объекта" заказать "вот такой уровень RAID". И если число девайсов и доступное место на них это в принципе позволяет изобразить - вы это получите.
> при ограниченном бюджете и не принимая в расчет сервера с кучей дисков,
> raid5 на 3-4 диска это самое оно,У btrfs RAID достаточно забавно сделан - админы привыкшие к тому что RAID фиксированно размещен по дискам и является какой-то определенной и более-менее фиксированной в плане его типа величиной - будут долго делить на ноль. Архитект btrfs не искал простых путей и решил что летать низко - не к нему. Не знаю тянет ли это на совсем новое поколение, но это совершенно иной подход и мне нравится такое мышление архитекта. Это круто и гибко. Чувак не любит проползать под планкой - он в настроении брать новые высоты.
> если вы хотите обезопасить свои файлы, но не покупать кучу дисков для зеркал.
Если вы хотите обезопасить файлы - делайте бэкапы. Ни RAID, ни снапшоты их не заменят. Желательно на физически отдельный компьютер. Потому что если у вас например пыхнет БП и overvoltage protection не сработает - синхронно умрет ВСЯ электроника. При этом все-равно - 1 у вас диск или 10.
> А про кодинг и тестирование - уже есть ZFS которая прекрасно работает, зачем?
Понятия о прекрасном - у всех разные. Древнючий CoW с рядом бестолковостей, без нормальных экстентов, без дефрагера, с дурным управлением памятью, отсутствием backrefs для простого и быстрого вынимания диска из пула и прочее - как-то совсем не предел мечтаний, имхо.
> Несомненно фича интересная, но вызывает много вопросов, например насколько хорошо оно будет
> балансировать данные между дисками,Если так вышло что баланс вам не нравится - есть ребалансер. Кроме всего прочего оно еще и гибкая штука в плане размещения данных.
> при наличии множества разных уровней raid и не будет ли кучи потерянного места.
Вообще-то куча потерянного места - это для начала про классические RAID с их деревянным допущением что все файлы имеют одинаковую ценность на продолб, а все диски обязаны быть одинакового размера. Это проще всего реализовать, но отнюдь не самое эффективное решение. На многодисковых конфигах btrfs может доюзывать место которое бы пропало на обычном RAID. Путем например использования разных сочетаний дисков. Как вам мысль: RAID-1 с блоками на "вот этом диске" может иметь *несколько* *разных* парных дисков для разных групп блоков? При этом все блоки будут иметь избыточную копию на отдельных дисках, но схема не будет жестко завязана на размеры дисков как таковые. При помирании диска все объекты с RAID1 имеют копию блоков на других дисках. При этом в degraded выпадает не "RAID вообще", а "объекты которые имели блоки на проблемном диске". Вот так вот.
> А также как оно себя поведет, если например у вас в пуле raid0 диск накрылся,
Ложки нет. И диска/пула "raid0" - нет. Такая фигня. Есть "raid0 у вон того объекта". А у вон того - raid 1. Если упал диск на котором было 2 объекта, один с raid-0 и второй с raid-1, объекты хранившиеся как RAID1 выживут за счет копий на других дисках. А raid0 на то и raid0 что ставит скорость выше сохранности, объекты хранимые как raid0 содержавшие блоки на проблемном диске будут ессно порушены. Придется вам перекачать прон заново. А рабочие документы перекачивать не придется. Мне такой подход видится куда как более разумным, чем то что сейчас, когда предлагается делать судьбоносное решение на века, а потом попробуй дескать это решение переиграть, не проклянув все на свете.
> но пару файлов вы как raid1 хранили - их конечно можно будет
> fsck выковырять я так понимаю..С логической точки зрения... метаданные всегда как минимум дублируются, если у вас многодисковая конфига. Так что ФС сама по себе не должна обрушиться в том плане что у нее будет исправная копия метаданных по которой можно продолжать работать как раньше. Участь файлов ессно зависит от того с каким уровнем RAID их было решено хранить. RAID-1 выживут за счет копий блоков на иных дисках, raid0 - помрут. А потом втыкаем новый диск на замену, говорим rebalance - и файлы которые в degraded - должны восстановить свою избыточность путем раскидывания копий на другие диски (новый + те на которых было место).
> Вот и я не понимаю почему такую элементарную вещь btrfs не может,
> а кому-то данные очень важны...Учитывая как btrfs работает с RAID - не вижу фундаментальных проблем класть блоки файла в 5 копиях на 5 дисков. При условии что у вас в системе как минимум 5 дисков в пуле с достаточным свободным местом в принципе было. Если вам такое надо и то что уже есть не нравится - ну, попробуйте попросить фичу, если можете внятно описать зачем так надо. Стоит понимать что для очередного RAID все-таки пилить логику рекавери и ряд утилит, так что безбашенно просить черти-что для красоты - не надо.
> Можно также спорить, что управление мешаниной из различных уровней raid тоже филиал ада.
Это филиал ада... но не для админа, а для ФС и ее разработчиков в основном. Так по крупнопу - вилы вылезли например вон в том вопросе по свободному месту. Потому что есть свободное место на дисках. Ничего не известно о том как попросят разложить данные. Если вы захотите raid0 - влезет так. А если raid-1 - эдак. И какую величину вам показать как прогноз "сколько уместится"? Ну так, с логической точки зрения :). ФС ведь не знает заранее - порево вы собираетесь дозаписать или документы.
Зато админ может переиграть судьбоносные решения в плане уровней RAID без тотальной перетряски всего убер-стоража на 100500 дисках. Это довольно круто задумано, а? Хоть и имеет странноватые tradeoffs.
> Хотя согласен, что при наличии всего двух хардов, наверно удобно документы хранить
> в raid1, а порно в raid0 на тех же дисках.Более того - можно запилить новую схему RAID ... без перетряски старых данных. Тот факт что ФС стала уметь raid5 и даже запись новых блоков в raid5 никак не мешает жить блокам в raid1 которые уже были. Они по прежнему будут raid1. На дисках будет некая смесь разных уровней raid а возможность починки при отвале будет пообъектно определяться уровнем RAIDизации объекта vs то что сдохло.
> Я знаю многих, у кого на десктопе raid5.
Ну ... допустим мне перестало хватать места на существующем raid5. Мои дальнейшие действия? А чтоб без эпического кластерфака? В btrfs в идеале - добавить 1-2 диска, может пересмотреть уровни RAIDов неких сущностей, ребаланснуть, чтобы новички в игру вступили, взяв часть нагрузки. Это просто и понятно. И ранее запрошенные уровни RAID для объектов никак не изменятся от самого факта "добавили 2 диска". И кто сказал что новые диски - того же объема что и старые, etc?
> Google тоже использует ext4 без журнала, потому что им проще тупо диск
> заменить если с ним что-то не так и засинхронизировать с другого сервера.ИЧСХ это вполне валидный подход. Более того - они сочетают скорость ФС без журнала с надежностью получше любого RAID, т.к. отдельно взятый сервак может вообще выгореть синим пламенем вместе со всеми дисками, а этого никто и не заметит. Я нахожу это весьма логичным устройством большой распределенной конструкции. В конце концов, вы не сможете бесконечно добавлять диски и делать 1 сервер все круче и круче. А они это могут масштабировать бесконечно.
> ZFSonLinux в IBM Sequoia используется например.
Мне не жалко, флаг им в руки. А для себя я хочу решение без типовых грабель ZFS и встроенное в майнлайн. Кстати те же IBM были одной из фигур за btrfs. Когда-то давно IBM, Oracle и кто-то еще устроили некое обсуждение и в итоге решили отбабахать ФС нового поколения, взяв лучшее из существующих дизайнов. Мэйсон попыхтел, посмотрел на существующие ФС и их проблемы, да и сделал btrfs. Как раз по заявкам этих слушателей. Насколько получилось - вопрос интересный. Но ряд дурных грабель старых дизайнов и правда остался за бортом, а такое сочетание фич не присутствует ни в какой другой ФС.
И, например, невозможность вырубить CoW механику под базой - это достаточно жирные грабли файловой системы, если что. Это накрывает медным тазом многие применения ФС с БД. Если так обратить внимание, те кому надо нагруженные базы данных - совсем не рвутся ZFS использовать. Там нет рукояток позволяющих захинтить ФС что базу не надо CoW'ать, а CoW базы с активной записью - ахтунг-ахтунг-ахтунг.
> В том то и дело, что zfs вполне можно доверить данные, поэтому
> статья и говорит что оно production ready с небольшими оговорками.Так доверяйте, я не против. Я просто высказал свое мнение насчет перспектив всей этой возни и устройства этой ФС.
> У ZFS тоже есть недостатки, в частности домашних пользователей печалит невозможность на
> данный момент удалить диск из пула (в проекте)Я не совсем понимаю как они намерены удалять диск из пула малой кровью. Для этого надо "рояль в кустах" - back references, позволяющие посмотреть кому принадлежали блоки и просто и быстро заапдейтить метаданные после перемещения блоков, чтобы блоки теперь искали в новой локации. В btrfs такое *заранее* предусмотрели. Ну то-есть, абсолютно нерешаемой эта проблема не решается, но когда архитект это еще на фазе дизайна явно предусмотрел - это сиииииильно упрощает дело. Более того - я не понимаю почему кто-то мнит что после столь крутой перетряски дисковой механики на самом базовом уровне все эти ахи-охи про стабильность будут применимы. Скорее всего под такое надо будет разворотить половину кода, а после таких изменений его весь надо будет тестировать с ноля и вылезет уйма новых вкусных грабель, ибо чудес не бывает.
> или добавит диск в vdev (Т.е. вместо raidz на 3 диска сделать raidz на
> 4 и сделать перестройку массива.Ну а вот в btrfs никакие бучие "перестройки" делать по сути не надо (кроме случая "диск сдох"). Можно вообще новый уровень RAID запилить никак не затрагивая существующие данные. А новые данные сохранить уже с новым уровнем RAID, например. Технически их подход позволяет наворачивать иные методы RAID, плавно и постепенно мигрировать на них без глобальной перетряски стоража. И такой стиль мышления архитекта мне, определенно, нравится. Он таки подумал о практических аспектах эксплуатации многодискового пула. При том подумал свежо и оригинально, рискнув сделать нетривиальные но многообещаюище решения вместо трусливого заметания проблем под ковер и упрощения себе жизни. Это как-то более честно чем замести технические проблемы, сделав как проще и вытянуть потом маркетинговым булшитом, как это любили делать сани.
> Добавить vdev к страйпу можно и сейчас
А если там не страйп - придется обломаться и ребилдить, да? :)
> и также можно заменить все диски в vdev на больший объем и сделать ресайз).
А в btrfs весь этот эпичный кластерфак просто obsoleted - by design.
> С памятью по большей части проблемы надуманы и в основном относятся к ONLINE! dedup,
А я склонен полагать что аллокатор без экстентов чудес производительности с неба не хватает и гигазы оперативы нужны в том числе и для вытягивания достаточно тормознутых свойств такого дизайна. Как вы понимаете, все новые дизайны ФС свалили на экстенты не потому что это модно, а потому что так лучше работает в большинстве нагрузок. Вкатить одним махом запрошенный регион - самое логичное решение которое можно придумать. Логично что это неплохо работает. Если задаться целью - завалить такую механику неудобной нагрузкой конечно тоже можно, но завалить можно любую механику ФС. Все ФС в среднем работают сильно лучше чем краевые worst case.
> который почти наверняка у BTRFS будет жрать столько же памяти, это почти неизбежно.
Btrfs не надо вытягивать тормоза аллокатора. Экстентные аллокаторы сами по себе довольно шустрые, без подпирания десятками гиг оперативы. Одно дело лопатить кучу блоков и метить это, и другое - если повезло то просто вбахать влобовую запрошенный регион, как просили, и на этом успокоиться.
> Но в целом на данный момент ZFS гораздо более надежна и функциональна
> по сравнению с BTRFS для большинства применений, кроме самых базовых вроде
> fs на одном диске/stripe/mirror.Возможно. Но говоря за себя - я предпочитаю увидеть btrfs доведенный до ума в майнлайне, а не странный zfs с кучей трудноустранимых грабель дизайна и где-то сбоку. Интеграция с системой - это хорошо. Куда удобнее поставить дистр на файлуху средствами штатного инсталлера чем сношать себе мозг с докачкой и отдельными бутовыми разделами и/или самоличным закатом солнца вручную.
Я не хочу всю жизнь ребилдить RAID. Это булшит. Я не хочу переворачивать полсистемы вкорячивая левые third-party модули. Турбореактивные самолеты стали основным средством перевозки. Даже если Туполеву и пришлось пару раз обтечь за первые ТУ-104, в результате винтовые самолеты - нишевая штука, а отнюдь не основное средство перевозки. Мэйсон сделал то же самое с уровнями RAID. Даже если ему придется пару раз обтечь - это не отменяет того факта что он применил ряд новых подходов, которые вполне могут задать новую планку, которую всем остальным придется или взять, или свалить на свалку истории как безнадежный хлам.
Вы повторяете одно и тоже про то как замечательно можно сочетать в одном пуле кучу уровней рейда, но это во-первых применимо только на базовых уровнях, и по сути основное применение это заставить что-то записать как raid0 вместо например raid1 или raid5 (я с трудом себе представляю как можно с raid1+0 перейти на raid5+0 без подсказок), во-вторых это уже ведет к граблям с разбалансом btrfs, когда оно вдруг начинает думать что у него места нет.
К тому же вы когда например raid50 делаете, стараетесь раскидать диски так, чтобы при вылете одного контроллера, не вылетел весь пул - я сомневаюсь что btrfs сама это сможет учитывать, а поэтому все эти умные штуки очень сомнительны.Это все круто, но сложно. Получится - замечательно, но пока оно далеко от готовности.
> И кто сказал что новые диски - того же объема что и старые, etc?
Диски разных размеров, это проблемы с производительностью в будущем. btrfs вам в лучшем случае их сможет использовать так, чтобы они данными заполнились равномерно, в худшем случае вы также потеряете то место, которое больше минимального диска.
> Ну а вот в btrfs никакие бучие "перестройки" делать по сути не надо (кроме случая "диск сдох").
И в btrfs надо делать перестройку и в ZFS, просто btrfs умеет делать ее на месте. Это круто в домашних условиях, может быть еще полезно на ненагруженых серверах.
>> Добавить vdev к страйпу можно и сейчас
> А если там не страйп - придется обломаться и ребилдить, да? :)Вы просто добавляете еще один vdev, ничего ребилдить не надо:
root@stellarwind:~# zpool create zfspool raidz /tank/zfs1 /tank/zfs2 /tank/zfs3
Заполнилось, добавляем еще места:
root@stellarwind:~# zpool add zfspool raidz /tank/zfs4 /tank/zfs5 /tank/zfs6
root@stellarwind:~# zpool status zfspool
pool: zfspool
state: ONLINE
scan: none requested
config:NAME STATE READ WRITE CKSUM
zfspool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
/tank/zfs1 ONLINE 0 0 0
/tank/zfs2 ONLINE 0 0 0
/tank/zfs3 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
/tank/zfs4 ONLINE 0 0 0
/tank/zfs5 ONLINE 0 0 0
/tank/zfs6 ONLINE 0 0 0errors: No known data errors
Переделать в один raidz1 на 6 дисков - нельзя, да.
> в результате винтовые самолеты - нишевая штука
Плохой пример :)
Расскажите это маленьким самолетам вроде Цесны. А потом посчитайте например сколько у нас Ту-95 и Ту-160. Если хорошо посчитать, может получится что на самом деле реактивные самолеты это нишевая штука.
> одном пуле кучу уровней рейда, но это во-первых применимо только на
> базовых уровнях,Это некое базовое свойство дизайна ФС - заранее подумали о том что для разных вещей могут хотеть разные уровни RAID. Поэтому оно технически допускает произвольную смесь RAIDов с пообъектной гранулярностью выбора.
> (я с трудом себе представляю как можно с raid1+0 перейти на raid5+0 без подсказок),
Как я уже сказал - ложки нет. Вы мыслите RAID на уровне блочных устройств. А тут RAID на уровне аллокатора, пообъектно. Допустим у вас пул из 10 дисков. Для btrfs есть 10 дисков. На дисках есть эн свободного места, на каждом по разному, например. Это суммарная рабочая площадь пула. Пришел юзер, попросил "RAID1 для вон того файла". Файлуха пошла и при записи положила блоки файла на диски номер 3 и 5, допустим. На дисках 3 и 5 стало меньше свободного места. Блоки содержат 2 копии, как просили. А потом еще дописали. И это допустим пошло на диски 4 и 9. На дисках 4 и 9 тоже стало меньше свободного места. Эти блоки тоже содержат 2 копии. Смерть ни 1 из дисков пула не приводит к потере всех копий. Т.е. условия RAID1 - выполняются.
А теперь допустим мы хотим сделать из этого ну пусть RAID5. Как это может выглядеть? Прочли блоки файла которые были сохранены как RAID1, записали их как RAID5 (если для этого достаточно дисков и свободного места), деаллоцировали блоки RAID1 (вернув место занятое под них), отапдейтили метаданные (чтобы указывали на новые блоки с новой схемой размещения). Вроде все логично и не вижу почему это не может работать. По сути конверсия любой схемы в любую с точки зрения файлухи - нечто наподобие копирования файла.
При этом можно добавить новую схему которая будет сразу использоваться для новых данных без перетряски старых данных совсем, а потом можно неспешно по мере желания старые данные читать и записывать с новой схемой размещения. А так чтобы немедленно подрываться конвертить данные на 100500 дисках - не придется вообще.
> во-вторых это уже ведет к граблям с разбалансом btrfs, когда оно вдруг
> начинает думать что у него места нет.Действительно, если вы допустим попросите RAID1, а свободное место есть только на 1 диске, извините, "места нет". Потому что нельзя выполнить запись по запрошенному критерию. С другой стороны, ребалансер может чего-то отыграть, равно как место может быть поюзано для иных схем хранения. В то время как на block-level RAID если диски разные, "лишнее" свободное место в хвосте диска как правило вообще втyпую пропадает.
Да, при этом понятие свободного места становится интересной штукой :-). А там еще CoW с GC, etc.
> сомневаюсь что btrfs сама это сможет учитывать, а поэтому все эти
> умные штуки очень сомнительны.Если не давит жаба чуть ли не каждому диску по контроллеру ставить - может не удавит жаба и делать в духе гугли? Там вообще "если 1 сервер умер, никто ничего не замечает" ;).
Ну то-есть я допускаю что какой-то нишевой юзкейс в таком контексте наверное может быть. Но в целом бояться только помирания контроллера, но не бояться смерти остальных компонентов сервера мне кажется довольно странным.
> Это все круто, но сложно. Получится - замечательно, но пока оно далеко
> от готовности.Фокус в том что если такие вещи не предусмотреть заранее, потом это заимплементить без тотального слома совместимости уже практически невозможно. А эти без проблем прикрутят те или иные схемы дублирования и четности RAID, при том существующим данным это жить никак не помешает. А потом при желании можно неспешно перемигрировать старые данные в новый вариант хранения.
> Диски разных размеров, это проблемы с производительностью в будущем. btrfs вам в
> лучшем случае их сможет использовать так, чтобы они данными заполнились равномерно,
> в худшем случае вы также потеряете то место, которое больше минимального диска.Место на "большем" диске можно потратить, например, для хранения файлов для которых избыточность вообще не просили. А ребалансер может до некоторой степени пролечивать ситуации, когда перекос по каким-то причинам вышел аномально крутой. Не идеально? Ну да, некий tradeoff с некими свойствами. Но мне такой ход мыслей нравится.
> И в btrfs надо делать перестройку и в ZFS, просто btrfs умеет
> делать ее на месте. Это круто в домашних условиях, может быть
> еще полезно на ненагруженых серверах.Это круто в том плане что все это можно делать без остановки работы ФС на фиг знает сколько и полного пересчета всего и вся. Плюс можно добавить 1-2 диска в пул и сделать ребаланс. Какие там уровни RAID у хранимых данных были и какие размеры дисков - не очень принципиально, ситуация с свободным местом всяко улучшится. В целом это позволит делать многодисковые конструкции гибче и переигрывать по ходу пьесы ряд решений без заваливания всего и вся в даун на черти-сколько.
> Заполнилось, добавляем еще места:
Теперь начинаю не совсем понимать я. Ну, ок, допустим я юзал RAID5. Теперь я хочу добавить еще 1 диск, чтобы суммарное место пула увеличилось. И как это будет выглядеть в терминах ZFS? И чтоб без разбора/дестроя многодисковых сущностей с полным пересчетом, разумеется. Btrfs отрастит +эн терабайтов на общей площади, изначально - "концентрировано" на этом диске, но после пинка ребалансера данные в фоне с всех дисков частично подвинутся на тот - в целом больше места станет глобально/независимо от типа RAIDа у разных объектов.
> Переделать в один raidz1 на 6 дисков - нельзя, да.
Ну а у btrfs можно в принципе перегонять объекты из одного типа RAID в другой по ходу пьесы. С технической точки зрения это read() с старой схемы, write() с новой схемой и снос старых блоков+апдейт метаданных. Ну так, чисто архитектурно. Что из этого по факту запилено - второй вопрос, по крайней мере та механика которая есть к таким вещам отнесется нормально и все это не проблема прикрутить, как и разные схемы избыточности/четности ... без порчи жизни админам на предмет разбора/пересоздания многодисковых пулов, масс-пересчета данных здесь и сейчас и прочего традиционного кластерфака.
> Расскажите это маленьким самолетам вроде Цесны.
Ну так я и не говорю что они совсем пропали. Но основной объем перевозок теперь на них.
> самом деле реактивные самолеты это нишевая штука.
По объему перевозок они давно все остальные обставили. А если смотреть на всякую мелочь, FAT давно всем врезал пинка: вон он на куче мелочи типа флешек и карт памяти :). Только вот почему-то нынче фат только на мелочи и остался, а использовать его на системном диске и хранилищах данных почему-то теперь никто не хочет.
> А теперь допустим мы хотим сделать из этого ну пусть RAID5. Как
> это может выглядеть? Прочли блоки файла которые были сохранены как RAID1,
> записали их как RAID5 (если для этого достаточно дисков и свободного
> места), деаллоцировали блоки RAID1 (вернув место занятое под них), отапдейтили метаданные
> (чтобы указывали на новые блоки с новой схемой размещения). Вроде все
> логично и не вижу почему это не может работать. По сути
> конверсия любой схемы в любую с точки зрения файлухи - нечто
> наподобие копирования файла.В Btrfs полноценная поддержка RAID5 и RAID6 до сих пор не реализована.
>> И в btrfs надо делать перестройку и в ZFS, просто btrfs умеет
>> делать ее на месте. Это круто в домашних условиях, может быть
>> еще полезно на ненагруженых серверах.А ZFS что по-твоему требуется, чтобы сделать перестроение vdevice в RAID1, RAID1 в RAID10?! То же, что и Btrfs — замиррорить объекты и разнести их части по дискам! И, да, это делается тоже в домашних условиях, а не в лабораториях. И, внезапно, для этого не требуется микроскоп и пинцеты. :))
>> Переделать в один raidz1 на 6 дисков - нельзя, да.
> Ну а у btrfs можно в принципе перегонять объекты из одного типа
> RAID в другой по ходу пьесы. С технической точки зрения это
> read() с старой схемы, write() с новой схемой и снос старых
> блоков+апдейт метаданных. Ну так, чисто архитектурно.Чисто умозрительно. Потому что рабочей реализации RAID5 и RAID6 в Btrfs ещё нет.
> Что из этого по факту
> запилено - второй вопрос, по крайней мере та механика которая есть
> к таким вещам отнесется нормально и все это не проблема прикрутить,
> как и разные схемы избыточности/четности ... без порчи жизни админам на
> предмет разбора/пересоздания многодисковых пулов, масс-пересчета данных здесь и сейчас
> и прочего традиционного кластерфака.Вот когда будет решена проблема с прикруткой RAID5 и RAID6 в Btrfs, тогда и поговорим. Ага?
Фантазировать можно долго.
>>> И в btrfs надо делать перестройку и в ZFS, просто btrfs умеет
>>> делать ее на месте. Это круто в домашних условиях, может быть
>>> еще полезно на ненагруженых серверах.
>
>А ZFS что по-твоему требуется, чтобы сделать перестроение vdevice в RAID1, RAID1 в
>RAID10?! То же, что и Btrfs — замиррорить объекты и разнести их части по дискам! И, да,
>это делается тоже в домашних условиях, а не в лабораториях. И, внезапно, для этого не
>требуется микроскоп и пинцеты. :))В данном конкретном случае они говорят про ситуацию: у вас raidz1 из трех дисков, вы хотите raidz1 из четырех - насколько я понимаю btrfs cможет (когда/если его вообще доделаю) добавить диск в raid5 и перестроить его с 3 на 4 диска на месте, перелопатив весь массив на месте.
В случае с ZFS вам для этого фокуса потребуется как минимум два новых диска (если вы рисковый товарищ), а в идеале вы втыкаете 4 новых диска, создаете новый пул, перебрасываете данные, грохаете старый. Не у всех есть даже один лишний хард, чтобы провернуть этот фокус.
>[оверквотинг удален]
>>
>>А ZFS что по-твоему требуется, чтобы сделать перестроение vdevice в RAID1, RAID1 в
>>RAID10?! То же, что и Btrfs — замиррорить объекты и разнести их части по дискам! И, да,
>>это делается тоже в домашних условиях, а не в лабораториях. И, внезапно, для этого не
>>требуется микроскоп и пинцеты. :))
> В данном конкретном случае они говорят про ситуацию: у вас raidz1 из
> трех дисков, вы хотите raidz1 из четырех - насколько я понимаю
> btrfs cможет (когда/если его вообще доделаю) добавить диск в raid5 и
> перестроить его с 3 на 4 диска на месте, перелопатив весь
> массив на месте.Btrfs RAID5 ещё несовсем умеет поддерживать. Это как раз та ситуация, когда "немножко беременна". ;)
> В случае с ZFS вам для этого фокуса потребуется как минимум два
> новых диска (если вы рисковый товарищ), а в идеале вы втыкаете
> 4 новых диска, создаете новый пул, перебрасываете данные, грохаете старый. Не
> у всех есть даже один лишний хард, чтобы провернуть этот фокус.Ну а вдруг до того момента, как Btrfs станет поддерживать RAID-5 в ZFS появится поддержка прозрачного расширения RAIDZ? Ну а вдруг?! Что вы тогда запоёте о целесообразности Btrfs?
машинки из TOP500.org с вами не согласятся
так никто не заставляет пользовать
>> вышедшая в марте прошлого года версия 0.6.1
>> подробно обосновал, почему он считает ZFSonLinux полностью стабильным и полнофункциональным продуктом
> Бугога, врать то меньше надо, товарисч китайоза. все мы знаем что zfs
> - тормозной глючный хлам.О.. один недоодмин, любящий тыкать кнопочки даже на posix ах себя уже засветил.
> О.. один недоодмин, любящий тыкать кнопочки даже на posix ах себя уже засветил.Ну нифига ж себе самокритика. Как там ваш putty.exe?
Смотри, однако, какие эксперты набежали - такие в каментах на опеннете не то что какого-то там Ричарда Яо опустят, а даже об самого Теда Тсо ноги вытереть могут.
> Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2 ...Да ну нах..., придумают тоже - лицензии на исходники... они бы ещё воздух по литрам выдавали.
diff -ur a/module/zfs/zfs_ioctl.c b/module/zfs/zfs_ioctl.c
--- a/module/zfs/zfs_ioctl.c 2014-06-13 00:58:09.000000000 +0400
+++ b/module/zfs/zfs_ioctl.c 2014-09-12 01:42:09.504964575 +0400
@@ -5893,6 +5893,6 @@
MODULE_DESCRIPTION("ZFS");
MODULE_AUTHOR(ZFS_META_AUTHOR);
-MODULE_LICENSE(ZFS_META_LICENSE);
+MODULE_LICENSE(GPL v2);
MODULE_VERSION(ZFS_META_VERSION "-" ZFS_META_RELEASE);
#endif /* HAVE_SPL */
Столлману только не показывай. А то засудят.
> Столлману только не показывай. А то засудят.Не Столлману а Ораклу. При том у оракла юристов больше чем блох на собаке, поэтому никто в здравом уме с ними пикироваться по судам не будет - если у вас нет бабла на адвокатов как у гугли, вам придется потом продавать последние трусы на оплату просpaного иска.
zfs наше всё, на лине она нафиг не нужна, фанаты торвальдса всё равно не оценят. а BSDшники уже оценили и давно используют.
> zfs наше всё, на лине она нафиг не нужна, фанаты торвальдса всё
> равно не оценят. а BSDшники уже оценили и давно используют.В BSD не ZFS, а жалкое подобие левой руки. Там уже написали ZPL? А лимиты ARC в ядро запилили? Ах, неееееет..... Ну, вот когда будет - тогда и прокукарекаете.
Да бздюкам не привыкать жpaть третий сорт который вроде бы не брак и при этом петь дифирамбы. Эти клоуны вон и про крутую графическую систему в юникс и бзд рассказывают гайководам. Попутно передирая из линуха DRM + KMS и со скрипом портируя ядерные куски кода соответствующие чему-то типа линукса 3.8, при том что в оригинале 3.17 уже скоро релизнется.
> Да бздюкам не привыкать жpaть третий сорт который вроде бы не брак
> и при этом петь дифирамбы. Эти клоуны вон и про крутую
> графическую систему в юникс и бзд рассказывают гайководам. Попутно передирая из
> линуха DRM + KMS и со скрипом портируя ядерные куски кода
> соответствующие чему-то типа линукса 3.8, при том что в оригинале 3.17
> уже скоро релизнется.может быть это просто по тому что уроды из линукса не хотят думать о портируемости?
Не научили их, или просто кривые руки. Хотя да - у вас есть шапка - которая всех заставит быстренько покупать у них сапорт контракты, ибо без этого вы ничего в своей системе не сделаете.
Круто звучит! А с чего это уроды из линукса должны задумываться над портированием своих разработок на другие платформы? Вы когда ремонт дома делаете, задумываетесь над тем, смогут ли у вас дома жить псевдо-рукокрылы с Арктура III или головоногие с Сириуса Б?
Более того - когда бздюки в своем уютном загончике пилят ни с чем не совместимые фичи - это как бы нормально. А когда другие делают так же, но более успешно - это ай-яй-яй. Прикольная логика.
> Более того - когда бздюки в своем уютном загончике пилят ни с
> чем не совместимые фичи - это как бы нормально. А когда
> другие делают так же, но более успешно - это ай-яй-яй. Прикольная
> логика.Ну конечно, когда сидишь и выскребаешь в FreeSwitchе "остатки недоношенного дитя" писанное Linux оидами, не могущими определиться, чтоже всетаки такое стандарт Posix, чтобы Switch запустить на BSD. Это явное и показательное выступление бардака в стане Linuxоидов.
> Ну конечно, когда сидишь и выскребаешь в FreeSwitchе "остатки недоношенного дитя"
> писанное Linux оидами, не могущими определиться, чтоже всетаки такое стандарт Posix,В POSIX нет hole punch, O_TMPFILE и уймы иных хороших и полезных ништяков. Кто-то должен еще и двигать прогресс вперед. И этим кем-то на данный момент зачастую являются пингвиноиды.
> чтобы Switch запустить на BSD. Это явное и показательное выступление бардака в
> стане Linuxоидов.А как по мне - это показатель того что с бздами кластерфак на ровном месте + показатель того что на них забили и не собираются с ними считаться.
> А как по мне - это показатель того что с бздами кластерфак
> на ровном месте + показатель того что на них забили и
> не собираются с ними считаться.Ну ты в очередной раз доказал свою недалекость.. Код который кроме Linux не запускается нигде, является проблемой для остальных POSIX систем и можно делать по этому вывод что на них забили?! Мда facepalm. Радикальный дЭбилизм. Не меньше
> Ну ты в очередной раз доказал свою недалекость..Ваши сообщения прямо эталон юного бсдшника-кулсисопа: ни единого технического аргумента, зато много рассуждений про свойства оппонента, (не)лохов и прочие "инженерно-технические" субстанции.
> Код который кроме Linux не запускается нигде, является проблемой для остальных
> POSIX системЭти POSIX-системы сами такой код пишут оптом и в розницу. Да и POSIX есть даже в винде. Можете ориентироваться на него, если хотите.
> Радикальный дЭбилизм.
Самокритично, чо.
Прошу на ТЫ :)
В англицком языке, как сказал мой очень хороший друг, Англичанин, БРИТ, профессор филологии, живущий давно в Алмате, лет 60 :-p
Сидели пили пиво. Спросил - он ответил
В английском языке нет обращения ВЫ в том смысле как мы привыкли думать :)
Он говорит - в том смысле обращаются только к КОРОЛЕВЕ и соответсвенно БОГУ. Моэтому множественное число
> Прошу на ТЫ :)
> В англицком языке, как сказал мой очень хороший друг, Англичанин, БРИТ, профессор
> филологии, живущий давно в Алмате, лет 60 :-p
> Сидели пили пиво. Спросил - он ответил
> В английском языке нет обращения ВЫ в том смысле как мы привыкли
> думать :)
> Он говорит - в том смысле обращаются только к КОРОЛЕВЕ и соответсвенно
> БОГУ. Моэтому множественное числоНа ВЫ, обращаются только к королеве и к богу
> В англицком языке,На третий день Зоркий Глаз заметил русский текст... :).
>> чтобы Switch запустить на BSD. Это явное и показательное выступление бардака в
>> стане Linuxоидов.
> А как по мне - это показатель того что с бздами кластерфак
> на ровном месте + показатель того что на них забили и
> не собираются с ними считаться.Да нет. Просто сейчас в тренде деградация технологий и людей. И GNU/Linux является одним из заметных показателей деградирующего качества архитектурных идей и программного кода.
P. S.
Идеи в Btrfs хорошие, но их реализация — полный отстой и fail.
> Просто сейчас в тренде деградация технологий и людей.Чему ты служищь живым примером. Вместе с твоим ZFSом, где вместо инженерного решения сложных технических проблем - громкий маркетинговый булшит от санок.
> И GNU/Linux является одним из заметных показателей деградирующего качества
> архитектурных идей и программного кода.На мое нескромное мнение btrfs в целом явно интереснее ZFS по сумме свойств.
> Идеи в Btrfs хорошие, но их реализация — полный отстoй и fail.
Ну так более хорошей реализации этих идей в таких сочетаниях не появилось. Если линуксоиды упираются 7 лет, бздюки стало быть не справятся и за полвека.
Если что, ядро линукс со всей его графической системой без проблем портируется куда угодно, просто берешь и запускаешь его на практически любой машине вместо bsd.
> Если что, ядро линукс со всей его графической системой без проблем портируется
> куда угодно, просто берешь и запускаешь его на практически любой машине вместо bsd.Инифига себе! Да вы читер?! :)
Иди уже ныть, как Oracle наклонил твой
любимый Solaris, в свой блог.
Любители Solaris'а даже с спапортом ничего
в своей системе сделать не могут.
> может быть это просто по тому что уроды из линукса не хотят
> думать о портируемости?Довольно сложно думать о портируемости, когда бсдшники просто самоустранились и заявили что их все и так устраивает. Ну а что делать тем кого то что есть НЕ устраивает? Правильно - идти своей дорогой и пилить самостоятельно. Что и было сделано. Потом оказалось что разработчики дров только этими механизмами и хотят пользоваться. Так что UMS был черти-сколько объявлен deprecated, и его наконец однажды отпилили, устав поддерживать древний код который разработчикам никуда не вперся. Вот тогда да, дошло. Ну и с остальным нехай так же будет. Заботиться о тех кого все устраивает - простреливать себе пятки. Если вас все устраивает по состоянию на 1990 - ну и пользуйтесь софтом 1990 года выпуска наздоровье.
> есть шапка - которая всех заставит быстренько покупать у них сапорт
Пусть попробует меня заставить, хочу на это посмотреть :)
> контракты, ибо без этого вы ничего в своей системе не сделаете.
А вот это мы будем посмотреть.
>Там уже написали ZPL?Не напишут никогда, патамушта все исходники как-то оказались на дисках с ZFS, а обратиться к ним без ZPL они не могут, пичялько.
> А лимиты ARC в ядро запилили?vfs.zfs.arc_max, не?
К сожалению всё наоборот - zfsonlinux отстаёт от freebsd реализации, до сих пор нет и не планируется в ближайшем будущем поддержки multi_vdev_crash_dump, spacemap_histogram, enabled_txg, hole_birth, extensible_dataset, bookmarks. Поэтому о полной совместимости говорить ещё рано.
> отсутствие средств для автоматизации антивирусной проверки новых данных через ClamAVВы уверены, что этой фигне место в коде файловой системы? ФС должна обеспечивать системные функции, а антивирусная проверка - это уже задача прикладных приложений
Если говорить за вирусы, то тут бы я с вами не согласился. Кто, кроме ФС, точно знает, изменялся файл или нет...
Любая прикладная программа знает - есть mtime, ctime и т.д. Для гурманов есть inotify.
Постфактум — да. А задачу проверки всех данных *до* записи в ФС вряд ли можно адекватно решить без участия, собственно, ФС.
LD_PRELOAD?
> LD_PRELOAD?Позаменять функции стандартной библиотеки? Это не исключит возможности обратиться к ядру напрямую. Да и подключать свою библиотеку к каждой запускаемой программе не выглядит хорошим решением. И не уверен, что для отличных от C/C++ языков это сработает.
Впрочем, это мнение дилетанта — не приходилось использовать LD_PRELOAD. Я ведь правильно понимаю, что суть здесь в замене функций из динамически прилинкованных библиотек на свои?
ptrace
А вы в курсе, что в ZFS много лет абсолютно официальный API для интеграции с антивирусами есть? Оно отлажено, проверено, работает...
> А вы в курсе, что в ZFS много лет абсолютно официальный API
> для интеграции с антивирусами есть? Оно отлажено, проверено, работает...А у Linux есть inotify. Он вообще от файловой ситемы не зависит.
С каких пор inotify равно интегрированной поддержке стандартного API/протокола?Попросите уж тогда Поттеринга запилить сначала systemd-inotifyd, systemd-antivirusd и systemd-icapd ;)
> С каких пор inotify равно интегрированной поддержке стандартного API/протокола?А стандартов описывающих такие вещи вообще нет. Вот каждый и городит как умеет. В линухе есть вот такое вот API. Ничуть не более и не менее "стандартное" чем в ZFS.
> Попросите уж тогда Поттеринга запилить сначала systemd-inotifyd, systemd-antivirusd
> и systemd-icapd ;)А зачем? API и так есть для тех кому оно надо. Этим апи могут и антивирусы пользоваться, если им надо.
Вообще то я на icap намекнулНу-ну, он, конечно же, совсем нестандартный - https://en.wikipedia.org/wiki/Internet_Content_Adaptation_Pr...
> Вообще то я на icap намекнулПардон, я думал что вас интересует информирование локального авера о изменении файлов, чтобы он их перепроверить мог.
> Ну-ну, он, конечно же, совсем нестандартный
Ну, сетевой протокол. Ну, понимается полутора программами. Если вы хотите сказать что это серебряная пуля - я хочу сказать что это булшит.
А почему была выбрана CDDL?Или они не с 0 писали?
Если бы каждый, рассуждающий в этой теме о лицензии кода, написал по строке качественного кода - получилась бы новая ФС.
В теме три десятка комментариев, я бы посмотрел на ФС в 30 строк :)Приступим, первая качественная строка:
#include <stdio.h>
Эх, дурилка, нельзя таких пускать программировать
int main()
{ // Copyright 2012 by Anonymous. Released under the GNU AFFERO GENERAL PUBLIC LICENSE Version 3
>>> #include <stdio.h>
>> int main()
> { // Copyright ...Ах...еть, три строки - три ошибки!!!
1. В драйверах/модулях Linux нет stdio.h
2. ... и уж тем более нет main()
3. комменты в стиле C99 запрещены.
да, качественного кода не получилось. Начинаем сначала.#include <linux/init.h>
> #include <stdio.h>Stdio? В *драйвере* *файловой* *системы*? Эхехехе, вот это отжиг.
> полнофункциональным продуктом, готовым для повсеместного применения
> ожидается поддержка AIOЧтож этот разработчик курит-то ?
Оно уже есть в мастер ветке: https://github.com/zfsonlinux/zfs/commit/cd3939c5f06945a3883...
Китаец же написал что будет в следующем релизе.
А вот скажите, на ПК RAIDZ лучше делать из трёх HDD или из четырёх? Со всех точек зрения, что выгоднее? (На материнской плате всего 6 разъёмов SATA)
Рекомендуется четное число дисков с данными. Т.е. для raidz (2k)D+1P, где k = 1..4
Тут популярно от автора zfs: http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/
Но там в основном речь про то когда у вас дисков дохрена, что лучше - больше vdev и меньше дисков в каждом или наоборот. Вывод: в целом пофиг, больше зависит от того чем вы готовы жертвовать - местом или iops.В случае одного raidz в целом лучше 4 диска, т.к. потеряешь меньше места, хотя больше шанс что проглючит еще и второй диск во время ребилда.
Микрооптимизации по количеству дисков будут иметь смысл только на каких-то строго особенных мелких файлах. Если вы базу данных гоняете, у которой блоки по 4-8 кб, будет без разницы.
Для чего ? IOPS нужны или стоимость гигабайта ?Mirror - в два раза меньше места, чем RAIDZ, но производительность в несколько раз выше.
Чтение происходит параллельно сразу со всех дисков зеркала.
Я даже Stripe использую на часто изменяемых некритичных данных.
Если важна производительность, то можно на SSD вынести кэш для чтения. Если есть надёжный SSD, то можно на него вынести кэш для записи (если он откажет, то все данные будут потеряны).Популярная статья: https://blogs.oracle.com/roch/entry/when_to_and_not_to
Рекомендуют.
RAIDZ1 vdevs should have 3, 5, or 9 drives in each vdev
RAIDZ2 vdevs should have 4, 6, or 10 drives in each vdev
RAIDZ3 vdevs should have 5, 7, or 11 drives in each vdev
В плане надёжности лучше из 5-ти делать 5+, хотя можно 3 диска в зеркало собрать но объём будет как от одного диска
5-яти
Нет ФС кроме BTRFS и Поттеринг пророк её!
> Нет ФС кроме BTRFS и Поттеринг пророк её!Глядя на то как Мэйсон аллоцирует место под уровни райда - ну вы там с вашими кукурузниками прикольно смотритесь. А чувак тем временем делает турбореактивный самолет.
> Глядя на то как Мэйсон аллоцирует место под уровни райда - ну вы там с вашими кукурузниками прикольно смотритесь. А чувак тем временем делает турбореактивный самолет.Кличко языку анонимов апплодирует стоя!!!
> Кличко языку анонимов апплодирует стоя!!!Иди позубоскаль насчет Кличко ему в лицо, только чур не жаловаться если он в нокаут отправит.
Стандартная баталия в комментах.Админы локалхостов говорят, что у них уже все давно и отлично работает. Это, несомненно, серьезный аргумент.
Религиозные говорят, что лицензия не та, только поэтому btrfs лучше. Еще более серьезный аргумент.
И т.д...
А ведь просто ответить на несколько простых вопросов надо:
Кто-то кроме Оракла верит, что btrfs готова?
Есть хоть еще один серьезный вендор, кот. то же самое объявил и рекомендовал использовать не на локалхосте?
Когда ZFS стала production ready? Насколько она с тех пор еще улучшена?Хрущев вон обещал коммунизм, некоторые люди пару десятков лет так и верили, ждали. Смотрите, как бы не прождать тоже еще лет так пяток...
Вроде SUSE официально поддерживает BTRFS.
Отстал от жизни :(Однако почитал release notes, а там столько ограничений и обещаний запилить что-то в будущем...
> Однако почитал release notes, а там столько ограничений и обещаний запилить что-то
> в будущем...Да, там много ограничений и недоделок. Но в дизайне заложен ряд вещей, которые позволяют много чего интересного. И не то чтобы другие этим могут похвастаться.
> Да, там много ограничений и недоделок. Но в дизайне заложен ряд вещей,
> которые позволяют много чего интересного. И не то чтобы другие этим
> могут похвастаться.Повторюсь...
Хрущев вон обещал коммунизм... Там в дизайне заложен ряд вещей, которые позволяют много чего интересного. И не то чтобы капитализм этим может похвастаться.
Как-то так :)
> Хрущев вон обещал коммунизм... Там в дизайне заложен ряд вещей, которые позволяют
> много чего интересного. И не то чтобы капитализм этим может похвастаться.Хрущев многовато пиндел и маловато делал. И эти "коммунисты" пороли горячку, в виде "сначала затолкаем штыками в глотку, а потом подумаем что делать дальше". Коммунизм является вполне логичным устройством мира ... после достижения определенных точек в развитиии прогресса. Но не ранее того.
А btrfs-ники никому штыками в глотку ничего не заталкивают. Пилят свой агрегат и постепенно оно приобретает очертания. Вот уже базовые сценарии вполне нормально и стабильно работают, баги более-менее удавлены и народ начинает экспериментировать с внедрениями. Понятно что в итоге найдут новых багов. И починят. Все большие агрегаты так делают и внедряют. Обычный процесс.
Название не удачное, существует вариант прочтения "ZF Son Linux".
> Название не удачное, существует вариант прочтения "ZF Son Linux".Здесь ещё один пробел лишний (не считая цитаты).
А я просто скажу: "Спасибо, парни! Мне эта FS очень нравится!"
От высокой температуры у меня грохнулись 2-а ИБП, из одной партии очевидно были, т.е. 2-а сервера некорректно закрылись(накрылись), линукс с btrfs после танцев с бубнами пришлось поднять из бекапа, а вот фря с zfs поднялась, правда ошибок на ней были, я бы сказал логические, сделал снапшот всей системы, заархивировал его, убил пул, создал по новой и возвратил снапшот назад и ничего не потерялось, как будто и не было сбоя, всего 3-а часа простоя...
Это я к тому, что сейчас наверное в продакшене лучше юзать zfs, нежели btrfs...
> с zfs поднялась, правда ошибок на ней были, я бы сказал
> логические, сделал снапшот всей системы, заархивировал его, убил пул, создал по новойИ чем этот кластерфак отличается от просто перераскатки из бэкапа?
Время от создания бекапов до падения 12 часов, время восстановления из бекапа, ну и данные наработанные за день, все упало как раз в конце рабочего дня...
Вообще сейчас проблема бекапов, я так считаю, в большом обьеме данных, в этом смысле снапшоты рулез...
> в этом смысле снапшоты рулез...Только снапшоты для начала вообще не замена бэкапов. А во вторых, объем снапшота - понятие весьма своеобразное. Вот что лично вы понимаете под "объемом снапшота"?
Конечно снапшоты не для бекапов, но вот сделать снапшот(слепок) работающей системы, который делается очень быстро и с этого слепка или его части уже делать бекап...
> Конечно снапшоты не для бекапов, но вот сделать снапшот(слепок) работающей системы,
> который делается очень быстро и с этого слепка или его части уже делать бекап...Можно. В том числе и в btrfs. И чего?
Да ничего
>подробно обосновал, почему он считает ZFSonLinux полностью стабильным и полнофункциональным продуктом, готовым для повсеместного применения.Какая жуткая чушь!
Проблем у ZoL навалом, особенно в конфигурациях xattr=sa & acltype=posixacl что особенно актуально для самбы! Дело доходит до повреждения пула и невозможности его импорта! Сейчас плотно общаюсь с одним из разрабов (Tim Chase) по этой теме.
Производительность ZFS в виде файлов на EXT4 со сжатием gzip-9 на чтение: https://www.linux.org.ru/forum/admin/10925460
> Производительность ZFS в виде файлов на EXT4 со сжатием gzip-9 на чтение:
> https://www.linux.org.ru/forum/admin/10925460Да, ты чо??! Уже http://www.webupd8.org/2010/06/btrfs-compression-lot-faster-... так скоро?? Кто ж так меряет? Меньше 2ух раз. Надо не меньше _пяти. И четыре года назад. >/<
> Производительность ZFS в виде файлов на EXT4 со сжатием gzip-9 на чтение:#>zfs с gzip-9 живущая в файловом контейнере на ext4 в 2 раза опережает сам ext4
А sqlite "в контейнере" опережал неуконтейнеренный... http://www.phoronix.com/scan.php?page=article&item=ubuntu_11... в 1.9 раза. Три года тому. >/<
+++Мальчик, ты тормоз? ---Кто? Я??!
>> Производительность ZFS в виде файлов на EXT4 со сжатием gzip-9 на чтение:
> #>zfs с gzip-9 живущая в файловом контейнере на ext4 в 2 раза
> опережает сам ext4
> А sqlite "в контейнере" опережал неуконтейнеренный... http://www.phoronix.com/scan.php?page=article&item=ubuntu_11...
> в 1.9 раза. Три года тому. >/<
> +++Мальчик, ты тормоз? ---Кто? Я??!На zfs-fuse!