После почти двух лет разработки состоялся (http://list.zfsonlinux.org/pipermail/zfs-announce/2017-July/... релиз ZFSonLinux 0.7.0 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Работа модуля проверена с ядрами Linux c 2.6.32 по 4.12. Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Debian, Ubuntu, Gentoo, Sabayon Linux и ALT Linux.
В рамках 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. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра. Стабильность кодовой базы ZFSonLinux оценивается как сопоставимая с другими ФС для Linux.
Основные изменения:
- Добавлена возможность делегирования непривилегированному пользователю прав на администрирование файловых системам ZFS. Управление правами осуществляется при помощи команд "zfs allow" и "zfs unallow";
- Непривилегированные пользователи теперь могут выполнять команды
"zpool list", "zpool iostat",
"zpool status", "zpool get", "zfs list", "zfs get" без необходимости добавления в /etc/sudoers;- Поддержка аккаунтинга и квот для объектов отдельных пользователей и групп. Для установки лимитов и просмотра состояния предлагается использовать команды "zfs userspace" и "zfs groupspace";
- Поддержка хранения контрольных сумм с использованием более надёжных криптографических хэшей SHA-512, Skein и Edon-R;- Поддержка прерывания работы команд zfs send/receive (например, из-за сетевого сбоя или проблем на удалённой системе) c последующим возобновлением выполнения операции;
- Возможность переноса сжатых данных из одного пула в другой при помощи команд zfs send/receive (данные напрямую обрабатываются в сжатом виде без промежуточной распаковки). Для включения сжатия представлена опция "-c";
- Обеспечена защита операций импорта пула в отказоусточивых конфигурациях - совместно используемый пул теперь одновременно не может быть импортирован на разные хосты (перед началом операции импорта теперь выполняется проверка, не запущен ли уже импорт на другой хост);- Возможность настройки параметров, отображаемых в столбцах со статистикой, выводимой командами "zpool iostat" и "zpool status". Например, в вывод теперь можно включить данные мониторинга SMART, параметры датчиков температуры, статус индикаторов и т.п.
- В команду "zpool iostat" добавлены опции "-l", "-w" и "-r", позволяющие наглядно оценить задержки и размер обрабатываемых в данный момент запросов в привязке к отдельным дискам;
- В команду "zpool scrub" добавлена опция "-p", позволяющая приостановить выполнение проверки целостности без её полной отмены (для возмобновления проверки нужно ещё раз запустить "zpool scrub -p");- Поддержка больших dnode, позволяющих увеличит производительность работы с метаданными за счёт сохранения внутри dnode расширенных атрибутов, ACL и символических ссылок, связанных с длинными именами файлов. Выигрыш особенно ощутим в системах с SELinux и распределёнными ФС, такими как Lustre и Ceph;
- Новые возможности режима JBOD (https://ru.wikipedia.org/wiki/JBOD) (представление нескольких дисков как одного целого с резервированием): автоматический перевод новых дисков в режим online; автоматическая замена выведенного из пула диска на новый диск; автоматическое подключение дисков для горячей замены в случая сбоя; индикация сбоев при помощи светодиодов; мониторинг проблем и автоматический перевод диска в состояние сбоя при превышении порога несоответствия контрольных сумм; возможность ручной пометки диска сбойным (zpool offline -f); режим multipath;
- Порция оптимизаций:
- Новый метод выделения буферов ARC, минимизирующий фрагментацию структур в оперативной памяти;
- По умолчанию хранение данных в кэше с использование сжатия с распаковкой налету; задействование векторных SIMD-инструкций CPU (sse2, ssse3, avx2, avx512f, avx512bw, neon, neonx2) в реализации RAIDZ и в коде расчёта контрольных сумм;
- Возможность применения аппаратного ускорения GZIP-сжатия (QAT);
- Ускорение работы с метаданными за счёт более активного использования многопоточности, пакетного выполнения операций и упреждающего запроса данных;
- Ускорение процесса восстановления избыточности в RAIDZ - теперь проверяется только целостность секций, подлежащих перестроению;
- Число фоновых обработчиков теперь выбирается динамически в зависимости от нагрузки, рабочие потоки создаются и отключаются по мере возникновения необходимости;- Добавлено 42 новых параметра для тонкой настройки работы модуля ядра.
URL: http://list.zfsonlinux.org/pipermail/zfs-announce/2017-July/...
Новость: http://www.opennet.me/opennews/art.shtml?num=46932
Опоздали. БТР уже набрал силу
> Опоздали. БТР уже набрал силуВ смысле кашки покушал и в качалку сходил?
Кто-нибудь вообще пользуется бтрфс?
> Кто-нибудь вообще пользуется бтрфс?мне кажется - их сравнимое количество с теми, кто вообще делает хранилки на линуксе.
Я могу понять отказ от выбора клонов иллюмоса в качестве платформы - никто не умеет настраивать, не на всяком железе заведется, а выбор и так ограничен, непонятно, что будет с проектом уже через год (хотя если за этот год хранилка выходит на стабильные параметры - то уже и все равно, никто хранилки не апгрейдит в здравом уме), но линyпс-то зачем?
Если тебе стремно использовать саморушащуюся xfs, тормозную ext4, write-only lvm под обоими или btrfs с ее вообще невменяемым поведением, то неужели не стремно использовать полуживой проект, отстающий от параллельных на пару лет (судя по перечисленным новостям), делаемый совсем уж горсткой разработчиков, который еще и в любой момент может развалиться в виду каких-нибудь очередных сдвигов мозга у Линуса и компании? Пусть он даже в десять раз лучше остальных перечисленных?
Кажется, только кажется.
В случае сдвигов мозга всегда можно не меняя ФС уехать на другую ОС. ZFS на сегодняшний день только вантуз не поддерживает (но это их проблемы). Плюс никто не гонит в проде использовать ветки из сырого будущего, которое ещё даже не в проекте.
Хранилки на линуксе делают, но вот большинство из них (которые тупо NAS'ы с минимальным количеством ОЗУ, лишь бы линух с FTP шевелился) не потянут ни btr, ни zfs.
Ну а больших плюсов у btrfs, которую пишет горстка разработчиков под одну ОС, и которая может развалиться ввиду каких-нибудь очередных сдвигов мозга у Линуса и компании - не вижу.
> В случае сдвигов мозга всегда можно не меняя ФС уехать на другую ОС.ой... вам мало истории с fuse-имплементацией банальнейшей ext4, потребной для, внезапно, почитания той же самой ОС той же самой fs, созданной из под другого процессора?
лично я бы "уезжал" путем разборки пула и сборки его заново на другой ОС с нуля, все остальное - это какой-то настолько стремный квест, что лучше бы на это время уехать куда-нибудь в тайгу - "и хрен вы меня найдете", если данные представляют какую-то ценность.
> Хранилки на линуксе делают
ну я, понятно, не о домашней коллекции порно. хотя если бы в свое время животные не сожрали все мои деньги, моя была бы как раз на zfs - ее требования к памяти при таком использовании немного преувеличены молвой, там важнее ecc и сетевая часть, если порно уже нельзя переснять в случае чего (я не люблю с бабушками, а пони столько и не живут вообще), а на флэшку оно уже не помещается.
кстати, у вантуза все в порядке - там своя "btrfs" (в смысле, NIH синдром) есть - только вот я даже не знаю, где тусуются люди, умеющие ЭТО готовить и знающие, где там лежат грабли.
Сборки с нуля? Имеется ввиду тупо скопировать данные во вновь созданный раздел? С заведомо умершей системы например ты такое сможешь? И зачем вообще? ZFS как-то волшебно меняется сама по себе в зависимости от ОС, если в неё не лезть специально?По вантузу... Там одних только лулзов с "динамическим диском" хватает, который, являясь костылём поверх ntfs, превращает при любых шитхеппенсах восстановление данных в локальный адок. Ну нафиг такое счастье
> Сборки с нуля? Имеется ввиду тупо скопировать данные во вновь созданный раздел?э... если это для тебя просто - у тебя слишком маленькая хранилка, нафига ж ей zfs ;-)
Обычно - архивация куда-нибудь на небыстрый но условно-надежный сторадж, и физическое пересовывание дисков, полок и всего-всего, с последующей установкой с нуля и тестированием под нагрузкой всего массива - если данные таки представляют хоть какую-то ценность. Если старые диски можно просто положить в загашник или вообще старую полку оставить для менее важных задач - это большое везение, в нашей падающей экономике малореальное.> ZFS как-то волшебно меняется сама по себе в зависимости от ОС, если в неё не лезть
> специально?для начала, пожалуй, стоило хотя бы выяснить, каков набор дефолтных флагов в каждой ОС, учитывая что сами версии zfs/zpool в них и вовсе будут разные. Какой, к примеру, у линукса по умолчанию record size, и точно ли такой же у иллюмоса? Я не знаю, но это придется выяснять.
Ягодки, как обычно, пойдут потом.Дальше - здравствуй другой сетевой стек, другие реализации сетевых fs или сетевых стораджей, поле для грабель просто непаханное, если ресурсы и время хоть как-то ограничены.
Я вот за пять лет (еще с zfs fuse) так и не нашел подходящего места, где мог бы поиграть с ZOL безопасно для окружающих.
При этом с freebsd все просто - поскольку выбор из коробки у нас между ufs2 со, хм, странностями, и zfs, и все это уже давно вполне помещается в виртуалку без видимых последствий (если еще патчик имени slw не забыть, или оставаться на девятке с arc_max), то опыта ковыряния в мелких инстансах у каждого, кто хоть где-то ее применяет, уже набралось. А это уже неплохое основание для выбора платформы под коробочку побольше размером. Тут не столько какие-то сокровенные знания, сколько уверенность, что ага, мы уже это делали, и примерно знаем, куды бечь, если что-то пошло не так.
> только вот я даже не знаю, где тусуются люди, умеющие ЭТО готовить и знающие, где там лежат грабли.Я например. Но ну енто нафиг - делать СХД на ОС общего назначения это глупость. Ну как минимум - ее надо хорошенько ощипать от всего лишнего... Собственно к сожалению это такая же неразрешимая проблема как и линакс на роутере - OpenWRT ее решило очень частично если что.
Вообщем к сожалению свободных замен Cisco IOS или NetApp ONTAP - нет и не предвидется. :(
А как же FreeNAS ?
> ой... вам мало истории с fuse-имплементацией банальнейшей ext4, потребной для, внезапно, почитания той же самой ОС той же самой fs, созданной из под другого процессора?ZFS искаропки умеет в auto LE/BE.
> Если тебе стремно использовать саморушащуюся xfs, тормозную ext4, write-only lvm под обоими или btrfs с ее вообще невменяемым поведениемПродолжая тему деревенских страшилок: zfs тоже стремная, требует терабайта оперативы, чтобы хоть как-то ворочаться.
>> Если тебе стремно использовать саморушащуюся xfs, тормозную ext4, write-only lvm под обоими или btrfs с ее вообще невменяемым поведением
> Продолжая тему деревенских страшилок: zfs тоже стремная, требует терабайта оперативы,
> чтобы хоть как-то ворочаться.А ещё от неё данные на ext4 "улетают"!!!
> Продолжая тему деревенских страшилок: zfs тоже стремная, требует терабайта оперативы,
> чтобы хоть как-то ворочаться.last pid: 78677; load averages: 4.00, 3.93, 3.10 up 14+21:22:57 14:59:12
61 processes: 5 running, 56 sleeping
CPU: 96.9% user, 0.0% nice, 2.9% system, 0.2% interrupt, 0.0% idle
Mem: 599M Active, 403M Inact, 2368M Wired, 276K Buf, 560M Free
ARC: 1050M Total, 181M MFU, 605M MRU, 16K Anon, 20M Header, 243M Other
587M Compressed, 1495M Uncompressed, 2.55:1 Ratio
Swap: 2048M Total, 2048M Freeну да, может повиснуть (маловероятно, в данном случае, но, теоретически, все еще может, причина толком не устранена, но после ресета поднимется, сто раз так делали), ну так про остальное перечисленное я знаю не теоретически, и там поднималось далеко не каждый раз.
world пересобирает, довольно уныло, но на сервис это не влияет, по крайней мере.
P.S. да, железка с ECC ;-)
я не очень понимаю, а сложно накинуть туда еще памяти по какой-то причине, если тачка реально используется для дела (да хоть пусть порно хранит!), а не концепт для тестов? Это же копейки, даже думать не надо
> я не очень понимаю, а сложно накинуть туда еще памятиэто мои деньги, я не люблю ими топить печку.
Памяти там с избытком для той задачи, которую эта виртуалка обслуживает, ее прежняя инкарнация на 8S+ufs умещалась в 256m (разумеется, она не очень пересобрала бы там мир, но это и не требовалось)К тому же практика коллег показала, что повиснуть без славиных патчей может и при 8G и при такой же вялой нагрузке.
при этом девятка с zfs при ограничении arc_max и тюнинге vmem может умещаться и в гигабайте без особо видимых глазом проблем. В 10 сломали ограничение, в 11 мне было низачем не нужно, но, скорее всего, с тем же патчем работает, а без него виснет рано или поздно.
> это мои деньги, я не люблю ими топить печку.а зачем тогда пересобираешь ворлд?
а это - не мои! ;-)
(ну и так на самом деле меньше проблем, чем со всеми модными-недоделанными системами бинарных апдейтов, особенно, когда живешь не на releng, а на stable)
Я пользуюсь и очень доволен.
>Кто-нибудь вообще пользуется бтрфс?а есть что-то получше для SSD?
> а есть что-то получше для SSD?md+ext4 без журнала, разумеется. Зачем тебе этот монстр для ssd?
Без журнала? Чтобы fsck руками делать, если свет ненароком вырубится?
>> а есть что-то получше для SSD?
> md+ext4 без журнала, разумеется. Зачем тебе этот монстр для ssd?а чем журнал то не угодил? очень странное решение, учитывая твой опыт. я хочу пояснений!
> а чем журнал то не угодил?тормоз он. Даже если не принимать во внимание "мой опыт" с автоприложившимся после падения битым журналом, превратившим почти исправную систему в полную кашу.
(сейчас в нем есть контроль целостности и барьеры, но это все добавляет тормозов, а осадочек после той истории остался)Плюс лишняя ненужная для ssd нагрузка по записи. Плюс повышенная (из-за большего числа операций записи) вероятность попадания именно в момент, когда что-то пошло не так, ssd может очень нехорошо на это отреагировать.
А вот как раз fsck на нем занимает секунды, даже если какие-то странные ребята и живут еще на "десктопе" без ups. (у меня обычной причиной fsck является не пропадание питания, а крэш, и вот, честное слово, я не хочу в этом случае никакого автонаката журнала, нет там ничего суперценного в последних пяти секундах, а вот уже якобы-накаченное лучше бы перепроверить на логическую непротиворечивость. То есть правильное поведение - ровно обратное умолчаниям)
И да, я так живу и на обычных дисках тоже. Ровно с момента, когда вычитал, что гугль сапгрейдил свои хранилки именно на этот вариант (вырвав себе приличный клок волосьев с воплем "да хрен ли ж я сам-то не сообразил") - там с измеризмами и анализом потерь, можно, наверное, еще где-то найти. Потерь данных с тех пор не было (2010? Или 9). А, да, у меня еще и strictatime везде где можно, я хочу иметь возможность узнать, когда тут кто-то лазил до меня.
стандартный ext4 с журналом + lvm только за последний год успел дважды разнести в хлам базу svn (я уже даже выписал себе на бумажку алгоритм восстановления, там нифига неочевидно и непросто) - причем это технологический svn, запись в который происходит раз в неделю в лучшем случае, и никакой другой дисковой активности там нет (помимо обычного системного шлака, разумеется). Да, там отваливалась хранилка, но если у вас ничего никогда не отваливается, то зачем вам вообще журнал?
c другой стороны сторожи под 20P живут на ext4 со стопочкой патчей .... может надо проверить железо слегка и потюнить ?
f2fs, не?
>Кто-нибудь вообще пользуется бтрфс?Поттеринг большой фанат бтра
Попробуй постучать в люк танка, может тебе кто-нибудь снаружи по морзянке ответит про btrfs, чему ты очень удивишься.
> Опоздали. БТР уже набрал силуКогда БТР научится работать с multipath - вот тогда на него и можно будет посмотреть! :)
А пока - детская поделка для локалхоста.
>> Опоздали. БТР уже набрал силу
> Когда БТР научится работать с multipath - вот тогда на него и
> можно будет посмотреть! :)
> А пока - детская поделка для локалхоста.А можно раскрыть тему? Что это такое и для чего нужно?
https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...И при чем здесь файловая система? Если это модуль для san сетей?
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
> И при чем здесь файловая система? Если это модуль для san сетей?Специально для админов локалхоста:
1. Удивись: БТРФС - это больше, чем просто ФС! Это вполне себе полноценная система управления внешней памятью, то бишь функциональная замена РАЙДов, ЛВМ и пр., т.е. элемент САН'а.
2. Сюрприз - в реальном производстве (когда в хозяйстве хотя бы несколько десятков физических серверов) работать на локальных дисках дорого, ненадежно и неэффективно. Поэтому используются если не САН'ы, то хотя бы решения попроще, типа полочек с дисками. А работать без резервирования связи - ССЗБ! :)
>БТР уже набрал силусилу земли, не срывая с грядки?
тонко
> Стабильность кодовой базы ZFSonLinux оценивается как сопоставимая с другими ФС для Linux.сопоставима со стабильностью btrfs или со стабильностью ext4? Это всё-таки разные вещи
вот именно, а еще не указана сопоставимость в процентном отношении. На сколько процентов сопоставима с ext4? На 89.5% или на 91.1%? Это все-таки разные вещи.
> сопоставима со стабильностью btrfs или со стабильностью ext4? Это всё-таки разные вещиименно что разные. Ящики сравниваем с яблоками?
Если сравнивать с ext4 over lvm на большом объеме - то там столько интересных способов навсегда потерять хранилку, что даже btrfs перестает выглядеть особенно стремно.
Руки отрасти из правильного места, и не потеряешь.
Причем тут руки? Ему бабушки у подъезда рассказали.
ext4 на объемах в 0.5P это жопа.. а zfs ничего.. живет.
> ext4 на объемах в 0.5P это жопа.. а zfs ничего.. живет.гораздо раньше. Я бы уже на 10T ее не рискнул бы использовать - даже если данные write-only, есть еще время восстановления сервиса.
если посмотреть на люстру - то ~256T - оно пережевывает - но потом начинаются чудеса.
> Руки отрасти из правильного места, и не потеряешь.Руки, места ... главное - лапы перепончатые!
Есть в этом модуле возможность ограничивать arc кеш ?
0. RTFM
1. modinfo zfs |grep arc
2. options zfs zfs_arc_max=$BYTES
> 0. RTFM
> 1. modinfo zfs |grep arc
> 2. options zfs zfs_arc_max=$BYTESнапомнить, сколько лет оно в freebsd вроде бы было, только не работало? ;-)
(я и про сейчас не уверен, но то что требовало этого ограничения, стало уже немного неактуально)
> Добавлено 42 новых параметра для тонкой настройки работы модуля ядра.То есть расписались в собственном бессилии сделать систему работоспособной в поставке "по-умолчанию." Интересно, сколько их вссего теперь насчитывается, не меньше двух сотен, наверное. Кто в здравом уме будет перелопачивать доки и тюнить всё это?
> Кто в здравом уме будет перелопачивать доки и тюнить всё это?ясно же кто! тот кому нужно не рабочее решение -- а провести время-провождение в режиме весело поиграть...
...то есть.. хм.. наверно типичный пользователь ZFS. :-)
остальные -- просто заиспользуют файловую систему встроенную в ядро, без неадекватнох телодвижений по привязыванию проволокой чужеродного говона. EXT4, XFS, BTRFS -- всем хватает в зависимости от необходимого количества желаемых плюшек.
# P.S.: в этом месте должен появиться фанат ZFS уверяющий что стабильность ZFS якобы сильно лучше чем стабильность BTRFS, выдумывая мифы про порчу данных на BTRFS :-D :-D :-D
Вон их уже двое вылезло выше.
Простите, а ZFS еще не готова к продакшену?
> Простите, а ZFS еще не готова к продакшену?Ещё не готова, но уже́ используется. Как и экстентные ФС. Как те же лекарства. Там, где выигрыш перевешивает риски.
В моём ареале обитания соотношение zfs:btrfs ≈10:1 "по головам".
Т.е. btr на одной _очень_специальной_ (виртуальной) ноде, где наличие рефлинков перевесило вероятность продолбать контент. А вот zfs подкладывается, в частности, под распределённые big-data системы. Потому что поблочные суммы и сжатие. Так что через годик-другой будет 20:1 и т.д.
> Простите, а ZFS еще не готова к продакшену?Не совсем. ZFS - не программа, это инфраструктура хранения. Сравнивать её с обычными FS - едино как сравнивать PostgreSQL с BerkleyDB. И этот монстр ДОЛЖЕН быть интегрирован в систему а не установлен сбоку. На памяти борьба ARC с системой за память и иные чудеса... Но если с памятью в машине проблем нет (или хотя бы оттюнен ARC) и ZFS стоит сбоку и держит некий сторедж, оно рабочее, даже очень.
Использую ZFS просто как есть, apt-get install и минимальной разметки оказалось более чем достаточно чтобы получить более чем работающую конфигурацию. Ты не осилил?
> Использую ZFS просто как есть, apt-get install и минимальной разметки оказалось более
> чем достаточно чтобы получить более чем работающую конфигурацию.и чем это отличается от горе-фанатиков, так же точно поставивших btrfs, или вовсе lvm с его миной с часовым механизмом?
"у них все работает", ага, и рассуждения о прямизне своих рук (а на деле - банальном ламерстве, то есть отсутствии и знаний о внутреннем устройстве - приносящих, как обычно, много горестей, и опыта за рамками домашней порно-студии) а потом - "мы не виноваты, оно само".
Ты шо? Святых заповедей сисадмина не уважаешь?
> вовсе lvm с его миной с часовым механизмом?Тут подробнее, пожалуйста.
>> вовсе lvm с его миной с часовым механизмом?
> Тут подробнее, пожалуйста.ну типа оно умеет в один непрекрасный момент превращаться в тыкву. Совсем, поскольку вместо метаинформации записывает мусор. Подробности очень старательно прячутся (кто-то на этом делает гешефты, кто-то боится распугать ентер-прайсных клиентов, в общем, такой секрет полишинеля), в целом, очень похоже на пресловутую фичу zfs+non-ecc+битовый глюк (только та-то отловит эту ситуацию и потеряет только часть данных, и визг поднимет вовремя, а в lvm никакого контроля record integrity нет by design, когда ibm его писала, такой проблемы еще не было)
А главное - никакой замены в общем-то нет, если тебе надо оперировать пулами и снэпшотами. Ну то есть вот я бы с интересом посмотрел на аналог нашей когдатошней поделки 2головыX4полки на чем-то другом-линуксном, но, желательно, с безопасного расстояния. А то если б та штука навернулась, можно было даже трех окладов не получить - при банкротстве предприятия работники являются кредиторами второй очереди.
> ну типа оно умеет в один непрекрасный момент превращаться в тыкву. Совсем,
> поскольку вместо метаинформации записывает мусор. Подробности очень старательно прячутся
> (кто-то на этом делает гешефты, кто-то боится распугать ентер-прайсных клиентов, в
> общем, такой секрет полишинеля), в целом, очень похоже на пресловутую фичуПохоже на теорию заговора. Кто прячет подробности-то, кто этот негодяй?
Хотя бы при каких вариантах применения и обстоятельствах тыквизация? Или вообще ни от чего не зависит?
Из личного опыта и опыта коллег (а контора большая) ничего такого, и вообще впервые слышу.
Нагуглить про самопроизвольную порчу метаданных пока не удалось ничего.
Да какая там теория заговора. Вы писанину пoциента в других обсуждениях почитайте.
Человек реально болен.
> Да какая там теория заговора. Вы писанину пoциента в других обсуждениях почитайте.
> Человек реально болен.Зачем вы так грубо?
*****
Сей персонаж,
Уже не раз,
Замечен за рассказом был,
Былин прохладных и историй.
И утверждений фееричных,
Под видом правды флегматичной,
Преподнесенных с умным видом.Но!
Будьте снисходительны!
Не виноватый он!
А мода сия,
Пришла к нам вместе с смузями и латте!
Ведь раньше было как?
Сморозил глупость раз, сморозил два
И балабокою тебя все записали!
Теперь же можно смело все писать,
И опеннеты субъективной правдой сотрясать!
А на вопрос «какого *уя?» отвечать:
«Вы все д**ьмо! Я Дартаньян и я так троллю!»
© Аноним
> Или вообще ни от чего не зависит?а как понять-то? Я вот не слышал, чтобы оно на домашних локалхостах так падало - но какой владелец домашнего локалхоста a) будет вообще ставить такую конфигурацию b) если ему системный установщик по дефолту такое сделает (когда-то, вроде, rh таким страдал) побежит искать помощи, а не переставит систему в стодвадцатьпятый раз "блин, опять не грузится", а порно с лошадками заново накачает, полный интернет его.
Две известных мне ентер-прайс херовины - пережили свои ентерпрайзы, там, правда, и ecc память, и вообще железо было далеко не с ближайшей помойки (ну то есть кому и супермикра помойка, но я и много похуже видал), но может быть нам просто повезло (в любом случае это было очень страшно).
А когда звонят знакомые-знакомых - там админчеги уже по стеночкам стоят, прикрывая ладошкой самой ценное "мы все правильно приседали и кланялись, а оно...вот..." - хрен ли толку их опрашивать, правды все равно не добьешься, да и пользы клиенту-то с той правды...
Одного я даже отправил к людям, которые как раз якобы умеют такое (при многих счастливых совпадениях) починить, сильно заподорого, ибо возня муторная, но назад он не возвращался, хз, вышло чего или банальный развод.
Обычные такие сервера, не распределенные хранилки, как те о которых выше, а традиционное такое "все в одном флаконе" и "зачем нам новый сервер, давайте старый апгрейдить". Ничего специфического.
но, опять же, владельцы навернувшейся распределенной меня ж не позовут, не моя тусовка, да я и не пойду, там сразу ж все ясно будет.
> там админчеги уже по стеночкам стоят,"Я тебе конечно верю, но и сам зве$дить умею"
У меня реально было, что человек при обычных работах на сервере взял и сделал dd на половину md-раздела (или там железный рейд был, не помню). Потом шлангом прикидывался, мол он просто туп0й. И разговор не о наказании человека. А о том, какой лапши они навешают (да и сам будет эту лапшу подогревать потом!), это же совсем не сложно. И делать далекоидущие выводы на таком анамнезе не следует.
> "Я тебе конечно верю, но и сам зве$дить умею"ну тут как бе несколько совпадений: 1. мне об этом говорили задолго до того, как я сам встал на эти грабли - по-моему, еще в 2007м (осторожно, это немного не тот lvm, который у нас сейчас) стало как-то принято во многих дистрибутивах по умолчанию создавать совершенно бесполезный lvm (бесполезный, потому что оно его создавало на весь единственный (прощай redundancy) диск и создавало на нем на весь объем fs (прощай снапшоты и прочее, для них просто не оставляли место) - и оно в общем-то "фсе работало", пока лично у меня не появилось время и вдохновение сформулировать резонный вопрос "нахрена" - от той же zfs без redundancy польза-то вполне есть) Наверное, слухи. 2. некоторые странные люди действительно заявляли "когда навернется - приходите, приносите мешок бабла", по-моему, еще в 2010м (а вот это уже нынешняя инкарнация). Наверно, врали. 3. когда не с мешком но с мешочком прибежали ко мне - я не поленился посмотреть, что там на диске в тех местах, где должны быть структуры, тем более, что они были умные и сохранили хотя бы /etc вместе с бэкапами метаинфы. А там - вермишель. Не нули, а просто случайно попавшие данные. При этом данные где-то там все еще были, возможно, частично, но как из них обратно собрать fs - я не придумал (ну есть у нас страйп с суперблоком, а следующий-то где искать?).
Ну и типа никто ничего не трогал (в смысле, оно не навернулось в момент какой-то операции именно с lvm, если с ним кто что и делал, то задолго до... или не сознались). И такая дребедень - не у одного человека, у нескольких в разное время. Физика в порядке, разумеется, насколько побыстрому это было можно посмотреть.
Соупадэниэ? ДА, СОВПАДЕНИЕ! ;-)
И не то чтоб zfs не могла навернуться тоже прямо на ходу, от тыщи и одной неведомой причины, но там во-первых, крайне редко бывает что вообще все данные с пула недоступны даже в r/o (и такие случаи были давно, что обнадеживает), во-вторых, примерно известны пусть не причины, но общие ситуации когда и как оно ломается и что при этом видно, ну и лично мне есть у кого спросить, кто этим живет и разбирается во внутреннем устройстве. (а у доступных владельцев хранилок на lvm "все работает" и представление о ее потрохах на уровне википедии)
Я подобные прохладные истории про ZFS могу рассказывать, при условии того что мой опыт работы с ней гораздо меньше вашего с lvm. И могу говорить что на lvm + mdraid + ext4/xfs никаких подобных проблем не возникало.
Что это доказывает? Только то что у нас разный опыт. Всё.С "совпадениями" вам на ТВ надо. А сюда было бы неплохо запостить более-менее авторитетные пруфы на описываемые вами проблемы.
> Я подобные прохладные истории про ZFS могу рассказывать, при условии того чтотак расскажите, я с интересом послушаю, у меня с zfs свой опыт слишком специфический, его опасно экстраполировать на большие системы (по специфике ZOL только не надо, я ей и так не верю).
Историю про файлы с дырками пересказывать не надо, она поучительная, но общеизвестная.> С "совпадениями" вам на ТВ надо. А сюда было бы неплохо запостить
> более-менее авторитетные пруфы на описываемые вами проблемы.я их не коллекционирую, мне-то оно зачем?
Да и как, по-вашему, должен такой пруф выглядеть - лежащий на полочке выдранный из сервера массив с битым lvm'ом, и рядом - маринованный мозг админа, который это настроил по найденным в гугле прекрасным инструкциям ?
> так расскажите, я с интересом послушаюА какой смысл? Он кстати вовсе не с большими системами связан.
> Да и как, по-вашему, должен такой пруф выглядеть...
Не воруйте шутки у Петросяна. Ссылки на профильные багтрекеры могли бы подойти.
> А какой смысл?умеющие читать и понимать прочитанное - добавят в свою коллекцию "чего делать не надо или где надо ждать подвоха". Неумеющие - в коллекцию глупых предрассудков.
> Он кстати вовсе не с большими системами связан.
вопрос не в размере, а в том, на чем именно вылезает - если как в соседнем треде "взяли хрень, сделали хрень, и потом случилась хрень", то, конечно, не очень интересно, а если на каких-то вполне обычных операциях - как раз и интересно знать, что за хрень и какие "обычные" действия ее могут вызвать. (даже если уже исправлено)
> Ссылки на профильные багтрекеры могли бы подойти.
для профильного багтрекера нужно поймать баг. А у тебя на руках рухнувший массив, который даже скопировать для экспериментов не на что, оно большое, и четыре бетонных блока едут к не-очень-Чистым прудам с прошлым админом внутри.
P.S. а порно с конями-то как раз ничего не угрожает, ни разу ко мне не обращались с просьбой восстановить рухнувший lvm с ним. ;-)
> а как понять-то?А иначе это есть суеверия и страшные байки.
> Я вот не слышал, чтобы оно на домашних локалхостах
> так падало - но какой владелец домашнего локалхоста a) будет вообще
> ставить такую конфигурацию b) если ему системный установщик по дефолту такое
> сделает (когда-то, вроде, rh таким страдал) побежит искать помощи, а не
> переставит систему в стодвадцатьпятый раз "блин, опять не грузится"У меня на всех локалхостах (кроме Малин) всё, помимо загрузочного раздела, на LVM, годами.
> а порно с лошадками заново накачает, полный интернет его.
Есть теория: виновато порно с лошадками.
> Есть теория: виновато порно с лошадками.Плюсую, учитывая фиксацию данного автора на порно.
никаких мифов делал тестовый сервак зимбры 100гб диск на Btrfs 0.19м пуле , у зимбры был разряженный бд файл на 80 гб который в сиситеме занимал 700к и отображался корректно при заполнении почто помойки данными свыше 20 гб получил fs crashed and remounted as ro
> никаких мифов делал тестовый сервак зимбры 100гб диск на Btrfs 0.19м пуле
> , у зимбры был разряженный бд файл на 80 гб который
> в сиситеме занимал 700к и отображался корректно при заполнении почто помойки
> данными свыше 20 гб получил fs crashed and remounted as roЯ правильно понял что вы делали пул из нескольких дисков на версии btrfs выпущенной в 2008 году? При том что она только родилась в 2007?
Ну так стоны примерно к этому обычно и сводятся - "мы взяли изврат, засунули в изврат, нагрузили до предела - ай, что-то пошло не так, подробности не расскажем".
взоржал, спасибо)
Юзал btrfs как /tmp.
Регулярные обновления Gentoo и периодические пересборки мира доканали btrfs всего за пару месяцев. Пытались ответить на ZFS, но реализация подкачала.
Когда юзал?
Чувак, у меня для тебя плохие новости. Gentoo пересобирается в /var/tmp/portage, так что твой /tmp на btrfs помер не от этого :-D
тогда значит бтр помер просто от _ничего_. Аазаза глючное п0делие!!1
>> Добавлено 42 новых параметра для тонкой настройки работы модуля ядра.
> То есть расписались в собственном бессилии сделать систему работоспособной в поставке
> "по-умолчанию."система _сложная_. На порядки сложнее всего, с чем ты, школьничек, имел дело.
Предполагаемая область применения - очень плохо предсказуемая, начиная от неведомой разработчикам аппаратной базы, и заканчивая неведомой им же нагрузкой.
Поэтому вполне логично оставить торчащие наружу ручки, а не прибивать гвоздем то, что сегодня кому-то показалось единственно-правильным, в надежде что угадал за всех и навсегда.> Интересно, сколько их вссего теперь насчитывается, не меньше двух сотен, наверное.
sysctl vfs.zfs | wc -l
151
ничего такого особенно ужасного - что-то под специфику дисков, что-то под особенности пула, что-то под тайминги. Вряд ли в линуксе сильно хуже.> Кто в здравом уме будет перелопачивать доки и тюнить всё это?
никто, кроме разьве что людей, занимающихся именно сборкой хранилок как основным видом деятельности, для них странно не разбираться в своем рабочем инструменте. Но столкнувшись с конкретной проблемой в конкретно своем окружении - любые обычные пользователи покрутят те две-четыре, которые для них актуальны. Причем, вполне вероятно - скопипастив чужое готовое решение, а не найдя его самостоятельно.
Вот из свеженького - compressed arc. Очевидно, что осмысленность зависит от камня, ресурсов, размеров памяти и хранилки, ну и того, что там внутри хранится, тоже. Большинству эту ручку трогать незачем - причем независимо от ее исходного положения.
Кому-то, тем не менее, вполне может пригодиться.P.S. на досуге предлагаю поизучать содержимое любимого линуксного /sys/block/sd?/queue/ и отдельно iosched (не забываем, что его содержимое в разных планировщиках - разное)
Документации, что характерно, нет, одни обрывки и отсылки к каким-то мертвым тредам в мертвых рассылках. Некоторый набор известных практик, тем не менее, существует. Большинство же даже не догадывается переключить свой ssd в non-rotational.
А это куда более примитивная и изученная область.
> Большинство же даже не догадывается переключить свой ssd в non-rotationalssd вообще-то по умолчанию non-rotational, и блочные устройства сделаные поверх него (следущим слоем) -- тоже автоматически non-rotational ..
ну или как вам там живётся в каменном веке?
какие параметры ещё в ручную переключаете?
> ssd вообще-то по умолчанию non-rotational, и блочные устройства сделаные поверх негоэто если оно правильно угадает. А теперь покажите мне типового линups юзверя, который это хотя бы проверить догадается? Они вон, смотрите тут повыше, f2fs на нем норовят заделать. Или вовсе btr... Ну откуда у них мозгам-то быть?
> ну или как вам там живётся в каменном веке?
> какие параметры ещё в ручную переключаете?я вам еще один страшный тайна открою - zfs тоже тюнит все эти параметры автоматически, только вот тоже не всегда удачно угадывает, особенно на нетиповых конфигурациях, которые авторам изначального кода (десять лет назад) в страшном сне не снились.
Большинству типовых пользователей с типовым мозгом версии 1.0, лучше как раз ничего там не крутить.
Крутить будем мы, те кто использует либо в очень ограниченных ресурсах, либо собирает большую хранилку под конкретную задачу и умеет проверять свои идеи тестированием.
Уже несколько лет пользуюсь для бэкапов и хранения архивов.
Полёт нормальный.
Кроме того - иногда пользуюсь для снятия данных с экпортированных томов из Nexenta.
Удобно.
> Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre.Вранье.. От zfs и zfs тима там ничего не требовалось. Просто люстре хорошо подходил zvol..
Как там дела с лимитом хардлинков?
Шифрование уже сделали (вроде как планировалось в 0.7.0)?
ZFS поддерживает спиннеры?
И гироскутеры
…встретились два фронтендера
Два смузи этому господину!
Пока требование ECC RAM не уберут - не нужна на десктопе.
И где работать ФС, в кэше процессора?
> И где работать ФС, в кэше процессора?на сервере, где ж еще. А что он там предоставляет -DAV свалку, iscsi-хранилище или вовсе самбой экспортит - дело десятое.
Застрявшие в эпохе "десктопов" должны страдать.
> Пока требование ECC RAM не уберут - не нужна на десктопе.десктопы не нужны, ага.
С ростом объемов HDD (см. заявленный BLER для HDD), требование ecc ram для десктопов скорее всем добавят.
> С ростом объемов HDD (см. заявленный BLER для HDD), требование ecc ram
> для десктопов скорее всем добавят.Как будто от наличия этого требования откуда-то возьмутся десктопные мазеборды с поддержкой ECC памяти.
Вы удивитесь, но они есть.
забыли про новую ZLOBA (ZFS Logical Objects Binary Architecture) написать.
Что там с удалением vdev из пула?
А zfs destroy ассинхронный (как у орков) осилили?
С момента объявления о готовности жду, когда сделают уменьшение количества дисков, расширение и сужение райд группы.
И ведь лет 6-7 назад говорили, что уже вот-вот, почти готово.
> С момента объявления о готовности жду, когда сделают уменьшение количества дисков, расширение и сужение райд группы.Удивительно дело — столько ждать, терпеть, не пользоваться и только поэтому? Вот это я понимаю — приоритеты и собственные принципы!!
> И ведь лет 6-7 назад говорили, что уже вот-вот, почти готово.
Кто говорил? Можно ссылку на это странное высказывание?
>> С момента объявления о готовности жду, когда сделают уменьшение количества дисков,
>> расширение и сужение райд группы.
> Удивительно дело — столько ждать, терпеть, не пользоваться и только поэтому? Вотну да, вдруг захочется диск сп...ть, времена нынче сложные, и очень нужны бабки для выплаты по ипотеке? А начальству какая разница, по инвентаризации все сходится - "сервер большой, 1штук"
> это я понимаю — приоритеты и собственные принципы!!
just a business, ничего личного!
>> И ведь лет 6-7 назад говорили, что уже вот-вот, почти готово.
> Кто говорил? Можно ссылку на это странное высказывание?ага, мне тоже интересно, учитывая что это как раз ключевая архитектурная особенность
> ну да, вдруг захочется диск сп...ть, времена нынче сложные, и очень нужны
> бабки для выплаты по ипотеке? А начальству какая разница, по инвентаризации
> все сходится - "сервер большой, 1штук"Вы, похоже, живёте в мире, в котором ничего никогда не меняется, и никто никогда не ошибается. Странный мир, не хотел бы я жить в таком.
> Вы, похоже, живёте в мире, в котором ничего никогда не меняется,
> и никто никогда не ошибается.работающие хранилки, которые нельзя просто увести в оффлайн и скопировать - не меняются, да.
Потому что ссыкотно, даже если ошиблись и получилась не очень оптимальная конфигурация, но она работает - хрен с ней, пусть уже дальше работает.сановские разработчики думали ровно так же, во всяких гайдлайнах эта фича тоже вполне описана - десять раз подумай, семь раз отмерь, и один раз отрежь немножко. Не думаю, что вам стоит ждать изменений в этой области - оно там довольно глубоко зарыто в архитектуру, сделать хорошо и надежно не получится.
(вариант сделать ребалансинг в виде долгой _деструктивной_ операции, при обломе в процессе которой пул накрывается совсем и необратимо, разумеется, мало кому подойдет)
>> С момента объявления о готовности жду, когда сделают уменьшение количества дисков, расширение и сужение райд группы.
> Удивительно дело — столько ждать, терпеть, не пользоваться и только поэтому? Вот
> это я понимаю — приоритеты и собственные принципы!!Почему не использовать? Использую уже лет 10, наверное. Но невозможность убирания устройств кажется запредельным унизительным идиотизмом.
>> И ведь лет 6-7 назад говорили, что уже вот-вот, почти готово.
> Кто говорил? Можно ссылку на это странное высказывание?Сам Adam Leventhal говорил. Ссылку за пару минут не нашёл, но мы ж не в суде, вы не обязаны мне верить.
См. block pointer rewrite. Его нет и вряд ли будет. Некому делать, вроде как...
Его не некому делать. Просто например Ahrens высказался, что если его сделать, то это будет последней фичей zfs, потому что там столько проблем с ним возможно, что добавление новых фич превратится в ад. В некоторых случаях гораздо проще просто скопировать с одного пула на другой.Собственно с btrfs как раз эта фигня творится, когда вы удаляете диск из пула, меняете уровни рейда, запускаете balance - оно может неделю и больше легко все это лопатить, даже на не очень большом пуле.
https://www.reddit.com/r/homelab/comments/57t5dj/btrfs_balan.../
Что там с поддержкой TRIM?
Ничего, лоеры и уборщицы не умеют писать код, в результате этому проекту, код неоткуда брать.
> Ничего, лоеры и уборщицы не умеют писать код, в результате этому проекту,
> код неоткуда брать.дельфикс - ни разу не лоеры.
И их код вполне себе берет апстрим, так что и не все уборщицы тоже.
>> Ничего, лоеры и уборщицы не умеют писать код, в результате этому проекту,
>> код неоткуда брать.
> дельфикс - ни разу не лоеры.
> И их код вполне себе берет апстрим, так что и не все
> уборщицы тоже.я про оракль
> я про оракльа, так там надо просто немного подождать. Лет через пять у единственного еще выжившего и почти вменяемого разработчика может руки и дойдут.
Зря ты так, пох. Орки асинхронный дестрой в 11-ой запилили. Завидую ах скулы сводит.
Уборщица шваброй провод выдернула, и всё асинхронно развалилось?
> Уборщица шваброй провод выдернула, и всё асинхронно развалилось?наоборот же ж - реинкарнировался уничтоженный снап с частью старого содержимого унутре.
Ну, или в плохом раскладе - не реинкарнировался, а содержимое лежит и жрет место, и удалить его уже никак, потому что нет снапа, нечего удалять.Но, по идее, scrub должен такое обнаружить и доудалять, а реальной угрозы диску сильно меньше, потому что в сто раз быстрее все происходит. Это если мы про ту async_destroy, что в freebsd и подобных.
> Зря ты так, пох. Орки асинхронный дестрой в 11-ой запилили. Завидую ах
> скулы сводит.это тот же самый, что у delphix'а ? Так он вроде с 12го года с нами, и включен.
feature@async_destroy enabled local
(active будет если дейстройнуть что-нибудь ;-)
Была у меня история, как-то решил что надо наш zoneminder перенести на linux + zfs, закончилось очень больно через пару дней, когда в системе подходило время для удаления данных. На сколько получилось понять уровень деградации хранения данных был максимальный и порция в 1000 файлов удалялась около 2х часов.... тюнил, крутил, бестолку...
В итоге командой пришли к тому что хранить что-то что сверх часто обновляется на такой системе просто не вариант. Вернулись на прежнее mdadm + raid0 из 4x 1TB и все по сей день летает без всяких лагов.
Что примечательно хостинг у нас досих пор под FreeBSD, порядка 40ка серверов и все на zfs, там нареканий почти нету... а вот с видеосервером оказалась лажа.
Аналогичная система крутится на FreeBSD, 12 HD камер, 2.6TB видео, старые записи чистятся каждый час, за час набегает примерно 12GB, все OK.
Похожая проблема с "долгим" освобождением места после удаления файлов была когда файловая система была проброшена в контейнер с помощью nullfs.
> Была у меня история, как-то решил что надо наш zoneminder перенести на
> linux + zfs, закончилось очень больно через пару дней, когда в
> системе подходило время для удаления данных.вы не на общеизвестные грабли с >80% заполнением пула налетели, надеюсь?
> обновляется на такой системе просто не вариант. Вернулись на прежнее mdadm
> + raid0 из 4x 1TB и все по сей день летаетсобственно, zfs вряд ли хорошая платформа для write-only данных, не вижу чем данное решение плохо.