Крис Мур (Kris Moore), создатель проекта PC-BSD и вице-президент компании iXsystems, объявил (https://lists.freebsd.org/pipermail/freebsd-current/2019-Apr...) о начале тестирования установочных сборок FreeBSD 12-STABLE (https://pkg.trueos.org/iso/freebsd12-zol/) и FreeBSD 13-HEAD (https://pkg.trueos.org/iso/freebsd13-zol/), в которых изначально поддерживаемая во FreeBSD реализация файловой системы ZFS заменена на наработки проекта "ZFS on Linux (https://zfsonlinux.org/)". Благодаря инициативе по обеспечению переносимости кода "ZFS on Linux" на другие системы, для FreeBSD были подготовлены (https://github.com/zfsonfreebsd/ZoF) порты sysutils/zol (утилиты) и sysutils/zol-kmod (модуль ядра), которые теперь предлагается протестировать. В контексте файловой системы, наиболее простым способом тестирования является предоставление готовых установочных образов, в которых изначальная реализация ZFS отключена и предустановлены порты с "ZFS on Linux". В качестве ФС для корневого раздела могут использоваться UFS и ZFS.
Напомним, что в декабре прошлого года разработчики FreeBSD выступили с инициативой (https://www.opennet.me/opennews/art.shtml?num=49815) перехода на реализацию ZFS от проекта "ZFS on Linux (https://zfsonlinux.org/)" (ZoL), вокруг которого последнее время сосредоточилась вся активность, связанная с развитием ZFS. В качестве причины миграции была упомянута стагнация кодовой базы ZFS от проекта Illumos (форк OpenSolaris), которая ранее использовалась в качестве основы для переноса связанных с ZFS изменений во FreeBSD. Поддержкой кодовой базы ZFS в Illumos до недавнего времени занималась компания Delphix, развивающая операционную систему DelphixOS (https://github.com/delphix/delphix-os) (форк Illumos). Год назад компания Delphix приняла решение о переходе на "ZFS on Linux", что привело к стагнации ZFS от проекта Illumos и переносу всей связанной с разработкой активности в проект "ZFS on Linux", который теперь рассматривается как основная реализация OpenZFS (http://open-zfs.org).Разработчики FreeBSD решили последовать общему примеру и не пытаться удержаться за Illumos, так как эта реализация уже сильно отстаёт по функциональности и требует больших ресурсов для сопровождения кода и переноса изменений. "ZFS on Linux" теперь рассматривается как основной единый совместный проект по разработке ZFS. Поддержка FreeBSD будет интегрирована непосредственно в код "ZFS on Linux" и развиваться в основном репозитории данного проекта.
Некоторые возможности, которые доступны в порте "ZFS on Linux" для FreeBSD, но отсутствуют в реализации ZFS от Illumos:
- Режим multihost (MMP (https://github.com/zfsonlinux/zfs/commit/379ca9cf2beba802f09...);
- Multi Modifier Protection);
- Расширенная система квот;
- Шифрование наборов данных;
- Раздельный выбор классов распределения блоков (allocation classes);
- Использование векторных процессорных инструкций для ускорения реализация RAIDZ и вычисления контрольных сумм;
- Улучшенный инструментарий командной строки;
- Исправление многих ошибок, связанных с состоянием гонки и блокировками.URL: https://lists.freebsd.org/pipermail/freebsd-current/2019-Apr...
Новость: https://www.opennet.me/opennews/art.shtml?num=50543
Ну посмотрим что из этого получится. Если его прикрутят к FreeBSD как в Линуксе аля "с боку бантик", тогда нафиг нужно.
А в чем кривость реализации в линуксе? Просто планирую перестройку домашнего nas с одним диском, и переход на zfs mirror. Какие приключения меня ждут? Btrfs хоть и линуксо-правильний и удобний но как-то я его боюсь...
> А в чем кривость реализации в линуксе?например - неумение управлять памятью - родовая беда самого линукса.
Решение пришло ВНЕЗАПНО - "а давайте нарежем всю память чанками по 4k". Что как бы говорит нам в том числе и о том, какая система стоит на столе у разработчика (видимо, маловат доход той конторы).Теперь прикидываем, как это будет работать в полупромышленной хранилке, где этой памяти полтерабайта и используется она, внезапно, по назначению - под кэш.
Наблюдения таки да, подтверждают гипотезу - ZoL неимоверно жрет cpu, поскольку поиск нужных 4k, как его ни оптимизируй, быстрым не будет.
> Просто планирую перестройку домашнего nas с одним диском, и переход на zfs mirror. Какие
> приключения меня ждут?да никаких - устанавливаешь 11ю фрю, штатным способом, она все сделает правильно, и пользуешься. abd и arc comp выключи сразу, само сжатие на диске - после тестов (с ним без arc comp есть ньюансы, вероятно, сводящие пользу к нулю, потому что такое никто уже сто лет не то что не тестирует, а вообще не проверяет).
А линукс для твоих целей - ненужно. Они десять лет TRIM не могут в своей ветке.К тому времени, когда во фре это доломают - твой домашний нас или рассыплется, или тебе надоест с ним играться, и еще десять лет он прекрасно проживет без обслуживания.
Если что, с самбой, nfs и драйверами mellanox у фри все в полном порядке.
> "а давайте нарежем всю память чанками по 4k"MMU у 32bit x86 аппаратно поддерживали страницы 4Кб. Отсюда и размер, а не с потолка или от дешевизны системы. В винде тоже 4К - самый распространненный размер страниц. Это позже уже hugepages вкорячили и TLB перестал cache_miss выдавать
> Отсюда и размера теперь подумайте верхней головой - сколько при заполненном полутерабайте у хранилки получится abd чанков и как вы будете теперь искать среди них нужный, сколько займет индекс подобных чанков, и что происходит с блоком стандартных для zfs 128k при чтении, при записи, при обращениях?
Отдельно об эффективности дерганья alloc/free на каждые 4k когда они понадобились/не понадобились (следить за экспайром тоже будете отдельно, перебирая все блоки - как еще-то?).
Что линукс не умеет нормального управления памятью в ядре - не вопрос, зачем только было этот код делать не линуксонли? У разработчика, очевидно, нет тестовых и рабочих систем большого объема, поэтому ему в голову вообще не пришло подумать. Или никого в ней не застало и ушло.У фри с ее zones этой проблемы, внезапно, нет.
Что страницы у вас 4k - совершенно необязательно означает, что хранить кэш диска надо блоками размером в страницу, а не размером в блок на диске, так, для разнообразия. Или даже в цепочку последовательных блоков, которую вернул prefetch - понадобится из середины, посчитаете смещение когда уже понадобилось - зато сам блок найдете в индексе в 64 раза меньшем.
Ну и на сладкое уже из самой freebsd - неумение kib@ и компании писать работающий код с первого раза, а не с пятнадцатого, если прямая копипаста невозможна. Почитайте комитлоги вокруг abd.c/h - просветлитесь. В том числе и их недоумению "а как это работает вообще".
Жоский ты человек Пох! :)
я просто реалист. Что вижу - о том и пою. Поводов для радости, увы, не вижу.
Нет, просто он думает как типичный железняк, а не специалист, который пишет низкоуровневый код и понимает все грабли x86 и их микроархитектур.
Он никак не думает.
Как он там сказал? Верхней головой? Так вот она у него просто не предусмотрена конструкцией. Бай дезигн.Зыж
По сабжу. Говорил я айзинке тут ещё лет 5-7 назад куда именно перетекла разработка openzfs.
Он (аргументированно надо сказать) спорил.
Но вот он сабж.
Ззыж
Да, про верхнюю голову.
Вот бтрфс реализован штатными средствами ядра линуха.
И это как раз то, что работает без вопросов. От слова совсем.
Ззыж
Да. С айзеном хотя бы было весело. (А до этого с занзвером)
А с этим даже комментить влом.
>Вот бтрфс реализован штатными средствами ядра линуха.
>И это как раз то, что работает без вопросов. От слова совсем.Если не вспоминать про стабильность и неумение терять данные, тогда да, вопросов действительно нет.
ЗЫ Оно в RAID хотя бы научилось? Сейчас вспомню, когда я завел файлопомойку с ZRAID на фряхе, первую из нескольких. О! В 2009ом году завел. 10 лет один и тот же zpool без потерь данных работает. Десять лет, Карл!
ЗЫЫ А эксперт 294го уровня по области файловых систем мне тут на опеннете те же 10 лет назад рассказывал, что btrfs уже одержал победу над zfs, и последний можно закапывать. Как вспомню, так смешно даже делается. У кого там btrfs в проде остался-то? Facebook уже мигрировал или еще в процессе?
> Если не вспоминать про стабильность и неумение терять данные, тогда да, вопросов действительно нет.
> ЗЫ Оно в RAID хотя бы научилось?Оно понимает что в ветке обсуждается выделение памяти?
Ну нет, так нет.
ну и у меня Linux mdadm на ехт3 12 лет проработал ... в продакшине ... это-ж надо какие живучие HDD попались
время это не главный фактор
скорее попался сказочно надежный луч питания.Один неудачный павердаун - и подобная конфигурация превращается в тыкву (тут и mdadm с его безусловной ресинхронизацией после некорректного останова, и ext3 образца 2000х, с ее неотключаемым накатом (возможно -битого!) журнала). Проверено, причем, увы, многими.
>>Вот бтрфс реализован штатными средствами ядра линуха.
>>И это как раз то, что работает без вопросов. От слова совсем.
> Если не вспоминать про стабильность и неумение терять данные, тогда да, вопросов
> действительно нет.Честно скажу, btrfs не юзал, но насколько я помню статус, у неё из нестабильных только raid56, всё остальное, говорят, окей.
> ЗЫ Оно в RAID хотя бы научилось?
Пишут, что научилось.
> Сейчас вспомню, когда я завел
> файлопомойку с ZRAID на фряхе, первую из нескольких. О! В 2009ом
> году завел. 10 лет один и тот же zpool без потерь
> данных работает. Десять лет, Карл!Ндык, zfs задал тренд на VMFs. Он был первым и лучшим, кто ж спорит.
> ЗЫЫ А эксперт 294го уровня
Нашёл кого слушать. btrfs до zfs ещё расти и расти. Местами, безусловно, она уже догоняет. Но её отлаживать ещё предстоит годы. Вон Red Hat, фрустрируя из-за этого, даже stratis запилила. ))
Как типичный железняк думает только тот кто считает что кроме x86 ничего больше нет. А ПОХ весьма разносторонне думает. И FreeBSD писалась не только для x86 поэтому использует правильные методы для Операционной Системы и ее архитектуры, а не железа на которой она крутиться.
Ну хорошо, допустим, в Линухе всё так плохо с управлением памятью при очень больших объёмах. Почему же тогда Линух почти вытеснил все остальные ОС из Top-500 суперкомпьютеров?
А допустим, что ты хороий программист, почему же у меня снег идёт?
Это же очевидно: потому что все, кроме поха, идиоты.
Потому что остальные ОС ЕЩЕ ХУЖЕ, разумеется.
Ахахаха. Интересно икается ли сейчас людям получившим нобелевку? Ведь они доказали что на рынке без регулирования выигрывает НАИХУДШЕЕ решение. А тут нате - всё пропало, тушеночный аноним с опеннета их разоблачил.
> на рынке без регулирования выигрывает НАИХУДШЕЕ решениес этого места попрошу подробнее. Кто доказал, когда?
>> на рынке без регулирования выигрывает НАИХУДШЕЕ решение
>с этого места попрошу подробнее. Кто доказал, когда?Насчет наихудщего я бы поправил, но без понимания критериев качества пипл жует что более блестит.
https://en.wikipedia.org/wiki/The_Market_for_Lemons
В статье представлен пример об износе которое сокрыто от покупателя и последний выбирает то, что более блестит. Не совсем пониманию, как это вообще приминимо к Linux и FreeBSD и применимо ли к софту вообще. Как софт может износится?Ну хорошо, допустим, Linux это "лимон" и он может изнашиваться во времени с помощью некачественной поддержки софта относительно FreeBSD. Это должен знать продавец "персиков" и "лимонов" и создатель "фруктов" (завод). Где находится неизношенная ОС и как она называется? Без неизношенной ОС невозможно установить где "персик", а где "лимон". Где эталон?
Получается, что ничего не получается с этой аналогией. Хорошо, я допускаю свою глупость и прошу пояснить лучше.
Аналогия совершенно некорректна. Вопрос не в износе а в разном количестве информации у продавца и покупателя. Посмотри русский вариант если интересно http://ecsocman.hse.ru/data/694/662/1216/5_1_4akerl.pdf
Никогда не попадал с аутсорсерами на "внезапно" возникшие непредвиденные затруднения?
> Ахахаха. Интересно икается ли сейчас людям получившим нобелевку? Ведь они доказали что
> на рынке без регулирования выигрывает НАИХУДШЕЕ решение. А тут нате -
> всё пропало, тушеночный аноним с опеннета их разоблачил.Вообще-то эмпирика достаточно ясно показала, что дело не в отсутствии/наличии регулирования, а в доступности информации. Если к "лимонам" теория может быть применима, то к большим и дорогостоящим железкам -- уже нет, потому что люди думают, прежде чем тратить большие деньги, и глубже вникают в вопрос, изыскивая свои, новые способы контроля качества, вовсе не завязанные на государственное регулирование.
Угу.
Вспоминается как Торвальдс Танненбауема послал с его сферическим цирком с конями в вакууме, аргументировав это тем, что в массовом рынке выигрывают решения, которые работают и ктоорые поддерживают.
Сколько было стонов про (подставьте свое значение) - такую систему загубили итп. В реальности оно само померло т.к. никому нигде не впилось.3552
> в массовом рынке выигрывают решения, которые работают и ктоорые поддерживают.Серьезно?
Ну да, Тлраальдс жеж спец по рынкам, базарам и прочтим житам.
> В реальности оно само померло т.к. никому нигде не впилось.3552Если под оно имелась в виду Minix, то оно вроде как вполне себе живо и даже доволно массово применяется (Intel ME).
https://firmwaresecurity.com/2017/05/07/intel-me-based-on-minix/
мужик, в TOP500 от линукса нужна только запускала MPI программ и возможность откусить лишнее.
стораджи и их OS - удивительно но не рассматриваются.
простите кому чего откусить?Это вы с чиновниками случаем не путаете?
> простите кому чего откусить?Экземплярам ОС на счётных модулях (узлах) "откусить". Там действительно выгодно иметь, как выше/рядом указывал коллега, чистой воды исполнялку плюс простейшая сеточка, а прочее отдать под счёт.
Сайту с топ500 — возможно.
А владельцам?
А! Попасть на сайт топ500.
Интересно, может даст кто нахалву поюзать годик. Много то и не надо. Процентов на 5 от номинала мочности.
А почему при средней ужасности во многих отношения ОС Windows Она господствует на десктопах. Ответ - поддержка железа. А ещё много народу считают другие ОС семейства *nix дистрибутивами Linux (сам офигел, и потратил время на просвещение, ибо страшно), а следовательно у Linux лучше PR. В копилку последнего, linux бы не существовал, если б Линус вовремя узнал о 386 BSD, ну или расклады были б немного иные.Меня во Фре раздражает многое, но всё относится к области отсутствия достаточных ресурсов чтобы заняться данным вопросом. Что не скажешь про Linux, которые местами выбешивает элементами дизайна ОС.
> Что страницы у вас 4k - совершенно необязательно означает, что хранить кэш диска надо блоками размером в страницу,Вообще-то означает. Потому что в процессоры встроена аппаратная система управления страничной памятью. Любое решение уровня "данные ещё не прочитаны" "данные изменены и должны быть записаны" не кратное, а лучше не равное страницам будет заведомо медленнее.
Неумение управлять памятью - внезапно беда кривой поделки ZFS, использующий свой собственный кэш вместо системного, а не линуксов. Системному кешу линуксов внезапно пофиг, сколько там памяти - полтерабайта или два терабайта, у него с поиском всё нормально.
> Системному кешу линуксов внезапно пофиг, сколько там памятиугу, он все равно абсолютно бесполезный. Поскольку не умеет отличить данные от метаданных, не знает ничего о размере блока fs и десяти линуксных прослоек поверх и линейным чтением вымывается на раз.
эта технология, как и нарезка блоками размером в 4k, была неплохим костыликом двадцать лет тому назад, когда в линуксе отказались от раздельных block и buffer cache, а заодно и от block devices в юниксном их понимании, а размер сектора был 512 байт.
С тех пор диски немножечко подросли, объем кэшируемого тоже возрос, и линейные поиски стали тормозом. Сан, работавшая с большими хранилками, догадалась вовремя, а линуксеры застряли в прошлом на своих уже почти еще окончательно готовых десктопах с единственным ide'шником под все.
И где ты в линуксовом менеджере памяти линейные поиски нашел, а поехавший ?Ccылки на исходники в студию.
А в какой версии был линейный поиск по page cache? До 2.6 (15 лет назад) там уже был хеш, а с 2.6 сделали radix tree:
http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/...https://lwn.net/Articles/684864/
К сожалению, он порой промахивается, всё так же уверенно давая оценки без квалификаторов "кажется", "помнится" и "вроде бы". Что сильно снижает применимость информации в таких комментариях, увы.
Ну в целом он прав, улучшения в page cache под huge pages только пока обсуждаются насколько я понимаю:
January 25, 2017
https://lwn.net/Articles/712467/He would like to revisit the idea of filesystems with a block size larger than the system's page size. That is something that people have wanted for many years; now that the page cache can handle more than one page size, it should be possible.
Да-да.
Потом эти же люди будут ждать прозводительности, стабильности, .., дефрагментации выделенной памяти, .., очистки мусора.
Первый раз что ли.Память выделяется страницами. На аппаратном уровне. Всё.
> Память выделяется страницами. На аппаратном уровне. Всё.все, п-ц, в линyпсе нормального кэша не ждите? Ну ооок.
где траву такую взял?.. и почем?ты слово Compound-Page слышал?... оно тоже выделяется и может быть произвольной длины.
Те же Huge Pages через них сделаны.
А еще есть slab.. который позволяет выделять объекты произвольного размера..
https://en.wikipedia.org/wiki/Memory_management_unitзыж
> А еще есть slab.. который позволяет выделять объекты произвольного размера..серьезно? можешь даже ткнуть в каком месте cpu он находится?
ззыж
а вообще,.. я желаю вам огромных успехов в реализации ваших идей в мелкoсoвте или ещё где.
главное не в нашем линyпсe :D
Под Linux в prod с 2016 года.Дома в mirror под home с 2017:
$ egrep -v '^#|^$' /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=3221225472
options zfs zfs_vdev_scheduler=cfq$ sudo zpool history | head -480 | grep -v import
History for 'tank':
2017-12-10.18:09:40 zpool create -o ashift=12 tank /dev/disk/by-id/wwn-0x5000039fe6d37a87
2017-12-10.18:13:17 zfs create -o mountpoint=/mnt/homes tank/homes
2017-12-10.18:14:26 zfs set atime=off tank
2017-12-10.18:14:52 zfs set atime=off tank/homes
2017-12-10.18:15:07 zfs set relatime=on tank/homes
2017-12-10.18:15:14 zfs set relatime=on tank
2017-12-10.18:15:55 zfs set compression=on tank/homes
2017-12-10.18:18:04 zfs set compression=lz4 tank/homes
2017-12-17.01:09:20 zfs set mountpoint=/home tank/homes
2018-01-02.01:59:12 zpool attach tank wwn-0x5000039fe6d37a87 wwn-0x5000c50079c65faf
2018-01-02.04:30:59 zpool add tank cache wwn-0x5707c181003b37e5-part1 wwn-0x5707c181003b37e5-part2
2018-01-14.00:24:08 zpool scrub tank
2018-01-20.18:54:38 zpool remove tank wwn-0x5707c181003b37e5-part1
2018-01-20.18:55:12 zpool add tank log wwn-0x5707c181003b37e5-part1
2018-01-20.18:57:06 zfs set sync=always tank
2018-02-11.00:24:09 zpool scrub tank
2018-03-11.00:24:09 zpool scrub tank
2018-03-17.01:57:13 zfs set sync=standard tank
2018-04-08.00:24:09 zpool scrub tank
2018-04-28.03:20:11 zfs create -s -V 60G tank/docker
2018-04-28.03:28:12 zfs set compression=on tank/docker
2018-04-28.03:38:47 zfs destroy tank/docker
2018-05-13.00:24:09 zpool scrub tank
2018-06-10.00:24:09 zpool scrub tank
2018-08-12.00:24:09 zpool scrub tank
2018-09-09.00:24:09 zpool scrub tank
2018-09-25.01:11:39 zfs create tank/docker
2018-09-25.01:15:39 zfs set mountpoint=/var/lib/docker/ tank/docker
2018-09-25.01:15:59 zfs set mountpoint=/var/lib/docker tank/docker$ zfs list -o name,used,logicalused,avail,logicalreferenced,refer,mountpoint,compression,refcompressratio,compressratio | grep -v legacy
NAME USED LUSED AVAIL LREFER REFER MOUNTPOINT COMPRESS REFRATIO RATIO
tank 2,29T 2,55T 348G 40K 96K /tank off 1.00x 1.11x
tank/docker 923M 1,48G 348G 25,6M 9,27M /var/lib/docker lz4 3.18x 1.74x
tank/homes 2,29T 2,54T 348G 2,54T 2,29T /home lz4 1.11x 1.11x
tank/libvirt 688M 1,19G 348G 1,19G 688M /var/lib/libvirt lz4 1.77x 1.77x$ zpool status
pool: tank
state: ONLINE
scan: scrub canceled on Sun Apr 14 03:58:33 2019
config:NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x5000039fe6d37a87 ONLINE 0 0 0
wwn-0x5000c50079c65faf ONLINE 0 0 0
logs
wwn-0x5707c181003b37e5-part1 ONLINE 0 0 0
cache
wwn-0x5707c181003b37e5-part2 ONLINE 0 0 0errors: No known data errors
За всё время использования - никаких приключений и дома и в prod.
До этого был один 1 год использования btrfs в качестве home:
тормоза, потеря файлов при выключении питания, жор цпу при поиске или работе сжатия, алгоритмов компрессии мало и ни не особо эффективны, как запихать ssd кеширование - хз, но сейчас может уже и не нужно.
Уже года два живу с btrfs на машине. Ни разу не было проблем с потерей данных на трех машинах. Возможно, дело в том что использовались только LTS ядра после 20-й версии.
> Уже года два живу с btrfs на машине. Ни разу не было
> проблем с потерей данных на трех машинах. Возможно, дело в том
> что использовались только LTS ядра после 20-й версии.Как я понял, это не связано с ядрами, а связано с тем как сбрасываются dirty pages на накопитель.
Может в последние пару лет, чего и подкрутили в драйвере btrfs и он стал надёжнее записывать данные.
Приключение, если можно так назвать -- чтение документации, она (от Оракла) слишком подробна и может испугать обёмом. Для домашнего nas хватит 5-10 страничек.Основные проблемы решены, в версии 0.8 (на днях вышел 4й кандидат в релизы) добавлена поддержка TRIM.
> Основные проблемы решены, в версии 0.8 (на днях вышел 4й кандидат в релизы) добавлена
> поддержка TRIM.ну молодцы, че. Жаль что фребеэсде с такой zfs все равно нафиг не нужно - у нас уже есть один zol, зачем нам второй? ;-)
>> Основные проблемы решены, в версии 0.8 (на днях вышел 4й кандидат в релизы) добавлена
>> поддержка TRIM.
> ну молодцы, че.Вот и ты будь молодцом, удали все свой трындёж про "TRIM никогда не будет" ;-)
> не нужно -
> у нас уже есть один zol, зачем намИ сколько там, Николай Второй, вас? 5? 10? Давно ли пришли к консенсусу?
например в домене AD для smb шар не очень годится, если для FreeBSD раньше можно было использовать VFS модуль zfsacl для корректного маппинга атрибутов доступа из семантики Win в POSIXACL (сама ZFS хранит в NFSv4, в близко к виндовой, но может работать в режиме и posixacl одновременно), то SAMBA 4 понимает только posixacl и в этом плане развернуть её прямо на ZFSonLINUX проблем нет, но попробуйте дать на каталог полный доступ всем, все атрибуты, даже смена владельца, у всех будут, кром... права удаления файла.. каталоги удалять, содержимое меняй, на удалить или переименовать файл уже не дать разрешения, только администратор как владелец файла (непосредственно root в самой ОС) сможет это делать... только недавно начали реализовывать отдельный набор утилит для ZOL разряда setfacl, getfacl но с поддержкой винсемантики
> А в чем кривость реализации в линуксе? Просто планирую перестройку домашнего nas с одним диском, и переход на zfs mirror. Какие приключения меня ждут? Btrfs хоть и линуксо-правильний и удобний но как-то я его боюсь...Ну вообще-то, если вы планируете использовать миррор, то btrfs достаточно стабилен. Единственная нестабильность btrfs -- это raid56. Плюс есть мнение, что частые рандомные записи не очень хороши на btrfs. Но это утверждение я не проверял.
В zfs же по части raid56 всё в порядке. Есть raidz, но имейте в виду, что он садит перформанс дисковой подсистемы. Причём нехило. Можно с медианы в 128мкс просесть до 2мс спокойно. Ну это для nvme. Для sata ssd получите в районе 10мс. Для plate jbod-ов не проверял, не было нужды.
В принципе, если вопрос не упирается в скорость дисковой подсистемы, то zfs безусловно маст хэв. Хранилище будет превосходным.
Какие приключения ждут? Ну, ожидайте, что запуск docker-контейнеров будет притормаживать, если вы его переведёте на storage-driver=zfs. Если обустраиваете root-on-zfs, то имейте в виду, что overlay2 поверх zfs почему-то не работает, и если /var/lib/docker находится на zfs, то этот storage-driver будет выбран докером автоматически.
Никогда не включайте дедупликацию. Она требует добавления в систему порядка 20гигов рамы на терабайт диска, и не предусматривает пути назад.
Включение компрессии -- по необходимости или желанию. Базы будете размещать, имейте в виду, что размер блока в zfs по умолчанию 128к. Чтобы базы производительнее были, поставьте датасету recordsize=8K.
По поводу root-on-zfs, если у вас пара датасетов, назовём их tank/var и tank/data, не указывайте mountpoint для tank/data внутри mountpoint для tank/var -- словите условие гонки при старте системы. Вместо этого создавайте nested dataset tank/var/data.
Ну вот примерно такие приключения вас ждут.
Очень рекомендую серию статей:
https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/Удачи!
> Никогда не включайте дедупликацию. Она требует добавления в систему порядка 20гигов рамы на терабайт диска, и не предусматривает пути назад.Это с чего бы не предусматривает? Но таки да, включать есть смысл разве что "на поиграться".
> Базы будете размещать, имейте в виду, что…
Не надо этого делать. CoW + CoW = fail.
> По поводу root-on-zfs
Плохая идея вне солярки. Разве что для развлечения. Если хотите иметь профит, старайтесь обходить проблемные места.
> raidz
Не иначе как продавцы "полок" разработчикам занесли. Нужно было серьёзно постараться, чтобы алгоритмически зафиксировать скорость не только записи, но и *чтения* с raidz.
¿А что с этим вообще можно делать?
Например, "подпирать" запись на медленные шпиндели быстрым твёрдотельниками. *Корректно* работающая альтернатива мне под linux неизвестна.
>> Никогда не включайте дедупликацию. Она требует добавления в систему порядка 20гигов рамы на терабайт диска, и не предусматривает пути назад.
> Это с чего бы не предусматривает? Но таки да, включать есть смысл
> разве что "на поиграться".Не предусматривает в том плане, что выключение дедупа не ведёт к уменьшению потребления рамы. Что было дедуплицировано, то останется таковым.
>> Базы будете размещать, имейте в виду, что…
> Не надо этого делать. CoW + CoW = fail.Вот за это -- спасибо.
>> По поводу root-on-zfs
> Плохая идея вне солярки. Разве что для развлечения. Если хотите иметь профит,
> старайтесь обходить проблемные места.А почему бы, собственно, и нет? zfs-снапшоты системы это всё-таки довольно удобно.
>> raidz
> Не иначе как продавцы "полок" разработчикам занесли. Нужно было серьёзно постараться, чтобы
> алгоритмически зафиксировать скорость не только записи, но и *чтения* с raidz.А можно подробности? Я не имел времени разобраться, почему zfs увеличивает латентность чтения, я просто наблюдал её и принял как данность.
> Не предусматривает в том плане, что выключение дедупа не ведёт к уменьшению
> потребления рамы. Что было дедуплицировано, то останется таковым.Хм. В моей картине мира ОЗУ отжирается в попытке держать все хэши "под рукой". Для этой самой дедупликации (нашёл одинаковый хэш — вставь ссылку на имеющийся блок /и с вероятностью ≈10^39 для SHA256 это таки верно/). При чтении оно отличается от случая "все блоки уникальные" только более компактным расположением данных. Постепенно рассасывающимся в процессе CoW. Я неправ?
>>> Базы будете размещать, имейте в виду, что…
>> Не надо этого делать. CoW + CoW = fail.
> Вот за это -- спасибо.На всякий случай, аргументированное противоположное мнение
https://www.opennet.me/openforum/vsluhforumID3/117278.html#88
Как всегда, нужно смотреть на условия применения. В описанном случае правильно спроектированный кэш в zfs даёт выигрыш больше, чем проигрыш от применения CoW.
* На обратной стороне dm-cache в linux, написанный какими-то хипстерами. Мне вот например нужно "подпирать" запись на медленные шпиндели быстрыми ssd. И как это в linux сделать?>>> По поводу root-on-zfs
>> Плохая идея вне солярки. Разве что для развлечения. Если хотите иметь профит,
>> старайтесь обходить проблемные места.
> А почему бы, собственно, и нет? zfs-снапшоты системы это всё-таки довольно удобно.Потому что данная ФС в linux "навесная". И проблем в таком кейсе будет сравнимо с btrfs.
Пример "от противного": положите на zfs swap-файл (mkswap и т.д.) и забейте как следует ОЗУ.>>> raidz
>> Не иначе как продавцы "полок" разработчикам занесли. Нужно было серьёзно постараться, чтобы
>> алгоритмически зафиксировать скорость не только записи, но и *чтения* с raidz.
> А можно подробности? Я не имел времени разобраться, почему zfs увеличивает латентность
> чтения, я просто наблюдал её и принял как данность.Алгоритмически я не разбирал (т.к. не готов исправлять). А замеры вот:
https://habr.com/ru/post/344204/
И кое-какие советы:
https://habr.com/ru/post/314506/
* И да, без ECC к zfs лучше не подходить. Как к любой БД, где нет желания расстаться с данными.
> Мне вот, например, нужно "подпирать" запись на медленные шпиндели
> быстрыми ssd. И как это в linux сделать?bcache?
>> Мне вот, например, нужно "подпирать" запись на медленные шпиндели
>> быстрыми ssd. И как это в linux сделать?
> bcache?Не поленился найти более-менее актуальный дайджест: https://habr.com/ru/company/first/blog/330040/
* bcache — отказать, т.к. скремблирует данные (посему ставится только в пару с пустым разделом) и в случае неисправности я не знаю что делать.
* lvm cache — afair, было только чтение. (Новый модуль от RH тоже дизайнили то ли программисты, то ли наркоманы. Им не накрыть VG, а на тестах я не увидел "вымывавания" кэша. Совсем. Засим попрощался.)
* flashcache — на локалхосте как-то работает. Игрался у себя на рабочей станции (openSUSE 42.1 на тот момент afair). Подпёр тогдашнее md-зеркало с xfs ≈2TB. Заподозрил потерю (мета)данных при включении write-back. (+ Модуль вгружался через раз из-за гонок, но тут уже́ моя лень править.)(!) Ни один из перечисленных не предоставляет опцию "подпереть очередь записи на устройство". Что, как мне кажется, наиболее прямой путь:
* Успеваешь — пиши прямо на шпиндели.
* Не успеваешь писать на шпиндель — пиши в кэш, пока есть место (fifo).
* Кэш тоже кончился? Вот теперь подождём (iowait)…
* Очередь разгреблась — пошли сливать (чистить) кэш на шпиндели.
Коллега прокомментировал так: "в ZFS есть intent log (ZIL SLOG)".
> (!) Ни один из перечисленных не предоставляет опцию "подпереть очередь записи на устройство".Я хочу дополнить коллегу Шигорина следующими соображениями:
Мы проверяли, ZIL именно это и делает. Если выносить SLOG на отдельный быстрый NVMe-диск, то разница в записи получается разительная. Я точные цифры тех наших изысканий не нашёл, но там где-то в 5-6 раз улучшение записи, емнип.
Также, помнится, 28го декабря прошлого года Чистяков в Dell EMC делал доклад по идемпотентному описанию архитектуры, где среди прочего упоминал в частности и эту тему тоже.
>Мы проверяли,
>на отдельный быстрый NVMe-диск,
>улучшение записиКак http://www.databasesoup.com/2015/02/running-with-scissors-mo... проверяли?...
> Ну посмотрим что из этого получится.да ничего в общем хорошего - баги сложнее опечаток по прежнему будут не исправляться а заметаться под ковер - теперь еще и с обоснованием "а так оно в апстриме" и "что полезло в рот ебе/редхату то и нам впихнется". Зато пацанам из iX будут и дальше платить зарплаты за копипасту, а вот два (или три) основных коммитера нынешей zfs с Украины (коммиты от людей, выдающих себя сейчас за "отцов проекта" там в лупу не разглядеть) - видимо, пойдут на мороз.
В чем, вероятно, и заключался тонкий политический ход - насколько я понял причастных, в проекте нельзя вот так взять и поменять что-то даже мелкое через головы людей, ведущих в данной подсистеме основную работу, а тут - опа, и внезапно работа идет вообще в портах, никто ваш код не трогает, проходите мимо ;-)
за кого болеть в битве жабы с гадюкой - не знаю, по-моему надо просто отойти от террариума, пока жабьей икрой не обрызгало с ног до головы.
А, ну и иллюмосу, очевидно - п-ц. В общем-то тоже не очень и жалко - нехрен было линуксный кал тащить в пасть (да, они вмержили неумение линуксеров работать с памятью).
Отрабатывайте наклоны и приседания - кланяться будем орацлу, и за почти работающую современную fs для линуксов (нет, это btrfs), и за ос для строительства хранилок (это solaris, ясен пень).
Кто еще будет выть про засилье корпораций - тыкаем пальцем в то, что получается, когда вместо корпораций любители на донейтах и зарплатах от куцых лавчонок с тремя работниками.
Слушай, пох, ты как-то обмолвился, что приходишь сюда потроллить любителей опенсорса. Я не осуждаю,
просто ты и нах, говните вообще все. К тебе и наху у меня один вопрос, а что из софта, не важно проприетарного или опенсорсного вам вообще нравится? Или беспросветное говно абсолютно все?
Но ведь это правда, в Open source как бы все кал.Пользовался этим вашим линуксом долгое время.
Все что в нем есть, это кривой графический стек, кривые старые иксы и не работающее ускорение видео в браузере в 2019 году!
Даже в кривой винде ускорение видео в браузере работает и графический стек нормальный.Так что пользуйтесь своими кривыми поделками сами.
О, приветик. А ты сам в зеркало посматриваешь хоть иногда? Кривизны там не заметил? А везде тебе кривизна мерещится.
Там извечное "доктор, ну а откуда у вас такие картинки?" (с)
То есть вы считаете, что в линуксе графический стек нормальный?Ну у убогих свои причуды...
Дядя, он-то кривой, как пространство-время в окрестностях черной дыры, только вот где взять что-то получше? В десяточке графический стек, конечно, на голову выше будет, зато качество ФС с лихвой перекрывает это достоинство. А еще там совершенно безумная система обновлений, да прогнивший реестр, который еще лет 20 назад уже поздно было выпиливать. Ну и в шпионаже за пользователем десяточка едва ли не догоняет андроид. Вдобавок, судя по всему, индус решил всех пользователей десяточки сделать бета-тестерами Windows Server. Спасибо, ребятки, но если я захочу бесплатно поработать на дядю, чтобы он денег загреб, я могу и федору взять.В macOS, хоть и нет безумных обновлений и реестра, однако же графический стек там в плане OpenGL еще хуже, чем в линуксе, а Metal все еще остается маргинальным поделием, и судя по всему, им и останется в будущем. Вдобавок там решили закопать не только OpenGL, но и OpenCL, не предложив взамен вменяемой альтернативы, под которую бы кто-то был готов портировать софт (CUDA там в силу давней ссоры Apple с nVidia давно уже незваный гость). Учитывая огромные даже по меркам США и остального золотого миллиарда цены на ноутбуки при ряде факапов типа той же клавиатуры, которая уже третье поколение как забивается мусором, требуя дорогостоящий ремонт - вариант с macOS тоже выходит очень кислый (лично для меня, но и не только). Да и забила на нее Apple, если уж честно. Не приносит она им прибыли по сравнению с iOS. Хотя даже с учетом стагнации экосистема macOS в плане стабильности, продуктивности и удобства пользования на десяток лет впереди всего остального. Вот только долго ли оно протянет на старых запасах?
В итоге что остается-то? Остается только надеяться на вяленого, ZoL, кеды и все прочие островки благоразумия и ментального здоровья, которые еще не ушли под воду.
Немного нейтральных уточнений про macOS
> графический стек там в плане OpenGL еще хужеТак точно, версии выше 3.1 в макось так и не завезли. Да и производительность УГ.
> а Metal все еще остается маргинальным поделиемЯ бы так не сказал. Всякие юнити и прочие анриал энжны сделали его поддержку, а на оставшиеся 5% огрызкоголовым плевать.
> Вдобавок там решили закопать не только OpenGL, но и OpenCLМитол, внезапно, может гонять вычисления. Прямо как вулкан. Просто под него переписывать всё нужно, а уже успешным разрабам лень, они хотят бабки получать.
> CUDA там в силу давней ссоры Apple с nVidia давно уже незваный гостьСсора, кстати, не очень давняя - примерно полгода ей. Нвидия до сих пор не выпустила дрова под последние операционки. Стороны обвиняют друг друга в этом. Сообщество, у кого макпро с нвидия картами под рендеры и прочую куду, люто бомбят и ничего не могут поделать, кроме как сидеть на тухлой 10.13.6. Собственно, я в такой же ситуации - не могу на хакинтоше с 1070 обновиться до последней оси, ибо нвидия превращается в тыкву.
>Всякие юнити и прочие анриал энжны сделали его поддержкуИгорей там все равно не будет, ну да ладно - я был неправ насчет маргинальности. Скажем так, это просто очень специфический API, который за пределами мира Apple не представлен вообще со всеми вытекающими из этого последствиями.
>Митол, внезапно, может гонять вычисления. Прямо как вулкан. Просто под него переписывать всё нужно
Может-то он может с недавних пор, только вот посмотрев на API я так и не понял, что мне нужно делать, чтобы написать свою функцию, которая на GPU считаться будет - то, что в CUDA называется kernel. Исходя из того, что я увидел, они предлагают пользоваться готовыми примитивами - типа посчитать FFT, перемножить матрицу на матрицу, или обучить нейроночку. Свои kernel - насколько я понял, фиг вам. Буду рад, если поправите мою неправоту.
>Ссора, кстати, не очень давняя - примерно полгода ей. Нвидия до сих пор не выпустила дрова под последние операционки.
Эта история повторяется каждый релиз macOS уже, наверное, лет 5 как. С момента последнего MacBook Pro с дискреткой от nVidia. Никаких рациональных технических причин для этого нет.
>Стороны обвиняют друг друга в этом.
Смешно же. Просто кое-кто в Apple абсолютно не заинтересован в нормальной работе карт nVidia. Ну а чо, возьмет какой-нибудь НяшМяш да поставит в свой Mac Pro (а то и вовсе в хакинтош!) свою 1070. Нет бы у партнера Apple рекомендуемую им AMD Radeon Pro впятьдорога купить.
Буквально несколько дней назад на ютубе чуваки воткнули макось на вируталку и завели в ней 1080 Ti вроде. Так что это скорее миф.
Полагаю, деградация того, на что потрачено много лет жизни, угнетает-таки.
И то, что процесс этот, видимо, закономерный, не утешает.
Не так-то всё просто с этой самой свободой.
> ты как-то обмолвился, что приходишь сюда потроллить любителей опенсорсатут, к сожалению, уже не троллинг - действительно очень жаль что оно кончится вот так. К длинному списку потерь прибавится еще и zfs, со всей остальной фрей заодно.
Потому что в то что это будет когда-то работать хотя бы не хуже чем в линуксе - я не верю, а зачем нам такая фря?идеальный софт бывает только в сферическом вакууме, как и идеальные разработчики, не закрывающие сообщения об ошибках с notabug/wontfix. Только вот заметно лучше софт не становится почти никогда (все реальные улучшения очень медленные и незаметные), а сделать его заметно хуже удается весьма легко.
Проектов, в которых подобного бы не происходило регулярно - мне, действительно, неизвестно.
> просто ты и нах, говните вообще все
ну так кто виноват,что другой субстанции нынче не осталось вовсе?
Так есть что-либо, что нравится или нет?
Да нет, нет. Вон раньше небо было зеленее, трава голубее, а сейчас всё — г… и все — п…
Я не пох, но таки программер и да, вообще любой софт, опен там он сорс или нет, абсолютное гавно.
Твой да.
И мой к сожалению тоже. Вообще IT индустрия это полный ппц с клиническими идиотами.
Покатайся пару годиков по стране, поговори с людьми разный профессий.
И обнаружишь, что эти люди, которых, ты называешь клиническими идиотами, ещё ого-го на общем фоне.
А самокритика это хорошо, поддерживаю.
Даже то, что называется абсолютным в природе, оно относительно. А значит, ничего абсолютного не бывает.
> просто ты и нахА ты ещё не догадался, что это один и тот же человек, как и "товарищ майор", "гугль", "редхат" и протчая, и протчая? :D
По почерку же видно (наверное, близнецами бывают телом, но не душой).
PS: я знаю, кто это, в прошлом веке ещё общались -- жаль, что человек выдаёт свои ценнейшие пласты набитых шишек именно в циничной манере, но это его выбор. К твоим сообщениям бывают аналогичные претензии у меня, а к моим -- не только у тебя.
> PS: я знаю, кто это, в прошлом веке ещё общалисьВ фидонете, поди? Есть у меня подозрение, что я его тоже знаю.
> А ты ещё не догадался, что это один и тот же человекза что никогда не любил опеннет, так это за вот эту помойку с никами.
пох - в основном я, ником "нах" помимо меня пользуется еще кто-то, эпизодически, еще есть с большой буквы - такое точно не мое.
товарищмайоров минимум трое (отличаются написанием).> жаль, что человек выдаёт свои ценнейшие пласты набитых шишек
да нет в них ничего ценного - вот были у меня ценные знания чего в фришной zfs патчить и крутить для конкретных узкоспециальных задач - ну и чего, вот, превратились в тыкву, нынче у нас совсем другая zfs и разбираться придется с нуля (или искать тех кто осилит разобраться и проверять что их советы подходят не только им) Знания в ИТ вообще недолго сохраняют хоть какую-то ценность.
ценно скорее умение угадать куды оно повернет в ближайшее время, но что-то последнее время и это стало слишком просто - ни с edge, ни с zfs, ни с эволюцией мурзилы - ни разу не ошибся, ну так там были два других варианта - вероятный - рептилоиды таки официально введут прямое управление, и сказочный - разработчики и их эффективные массово поумнеют.
Это типичная сисадминская проблема: разработчики говнокодят а им потом в этом разбиратся.
И выход естественный - самому говнокодить :)
Просто не надо ничего изучать впрок. Напрасная трата сил. Есть задачи, есть усилия, есть оплата. Мне жаль таких как Вы.
> Просто не надо ничего изучать впрок. Напрасная трата сил.
> Есть задачи, есть усилия, есть оплата.Это, полагаю, не овощное даже существование (те хоть растут), а винтика в механизме.
> Мне жаль таких как Вы.
А нам -- таких, как вы. Но каждый сам выбирает.
>> Просто не надо ничего изучать впрок. Напрасная трата сил.
>> Есть задачи, есть усилия, есть оплата.
> Это, полагаю, не овощное даже существование (те хоть растут), а винтика в
> механизме.Именно винтика. Сел на стул и расти. Как Вы относитесь к положению некоторых людей, например:
Потратил 15 лет на gentoo и понял что она не нужна.>> Мне жаль таких как Вы.
> А нам -- таких, как вы. Но каждый сам выбирает.
> Просто не надо ничего изучать впрок. Напрасная трата сил. Есть задачи, есть
> усилия, есть оплата.И зачем вам платить за то, что вы сейчас собираетесь неспешно изучить (по копипастам со стэковерфлоу)? Таджик и дешевле, и работящее.
Есть задача, есть специалисты, умеющие ее решать - _хорошо_. А не сейчас-быстренько-накопипастить-потом-дочитаю-как-оно-работает.> Мне жаль таких как Вы.
да, в мире копипастеров и "все решения уже есть в гуле" грамотным людям не место, это верно. Дешевле нанять макаку, освоившую быстропоиск.
но у меня все еще остается выгул собак в качестве бизнеса. "быстренько накопипастить" не получится, могут укусить.
> баги сложнее опечаток по прежнему будут не исправляться а заметаться под коверТак сам же пишешь, что как не принимаются, так и не будут приниматься. Т.е. ничего не изменится.
Я, кстати, даже догадываюсь, про какие баги идёт речь. И патчи не принимают как раз упомянутые тобой коммитеры с Украины (ибо они мэйнтейнеры).> Кто еще будет выть про засилье корпораций - тыкаем пальцем в то, что получается, когда вместо корпораций любители на донейтах и зарплатах от куцых лавчонок с тремя работниками.
Ну вот разработка ZoL (именно в Linux) оплачивается какой-то большой и толстой конторой. И как, хорошо?
Я бы не мешал все проблемы в одну кучу. Корпорации и их засилие - одно, непонимание фрибсдшников, как и на какие деньги эффективно и независимо развиваться - это другое.
Имхо, шило на мыло. Раньше тащили из одного апстрима, теперь будут из другого.
Порт - это, я так понимаю, временная мера.
> Ну вот разработка ZoL (именно в Linux) оплачивается какой-то большой и толстой конторой. И как,
> хорошо?ну какая ж она большая и толстая - сравни с орацлом или даже саном времен его заката.
Неплохо. Для линукса. То есть в линухе оно в общем и целом работает, в общем-целом стабильно, немного жирновато жрет (нагрузки от самой zfs во фре ты не увидишь без специальных инструментов, в линухе - просто top будет ей забит) но современные камни переварят. Вон, даже TRIM есть, теперь.
Ну online resize с глюками, но это, похоже, они как раз черезмерно копипастнули сановского кода, теперь страдают. Если бы не лицензионные войны - может уже и зохватила бы мир.> Порт - это, я так понимаю, временная мера.
там будут ньюансы - насколько я понял объяснения имеющих коммит-бит - там нельзя взять и закоммитить кусок кода, у которого есть типа-владельцы, через их голову. (а вот новый порт создать можно, и для этого даже коммит-бит портовый не нужен - достаточно попросить кого-то, у кого он есть) Вопрос лишь в том, будут ли нынешние трое упираться, подозреваю, что нет - "и баба с возу, и волки сыты". H1b им все равно не светит.
раньше был выбор, тащить мусор или выбросить на входе (ну и втащили его таки опционально, abd - отключаем). Теперь скорее всего - не будет, некому фильтровать.
>> Ну вот разработка ZoL (именно в Linux) оплачивается какой-то большой и толстой конторой. И как, хорошо?
> ну какая ж она большая и толстая - сравни с орацлом или даже саном времен его заката.По сравнению с ними не толстая, да.
> Неплохо. Для линукса. То есть в линухе оно в общем и целом работает, в общем-целом стабильно,
Да я не про это. Понятно что неплохо, у меня в линуксе тоже норм работало. Ты топишь за вмешательство корпораций, как за благо. Вот, ZoL спонсирует корпорация. В результате OpenZFS загнулся и все мы теперь будем хавать подачки с барского-линукс стола. Это прямое следствие вмешательство корпорации. Была бы на "стороне" FreeBSD ещё одна корпорация, у нас сейчас было бы не 2 а 3 несовместимых ZFS, только и всего (хотя ZoL и OpenZFS и так уже местами не совместимы, да).
>> Порт - это, я так понимаю, временная мера.
> раньше был выбор, тащить мусор или выбросить на входе (ну и втащили его таки опционально, abd - отключаем). Теперь скорее всего - не будет, некому фильтровать.Посмотрим. Я пока сам до конца не понял, как хуже: так как сейчас или как будет с ZoL.
В целом, это всё слегка нагнетает уныние.
>>> Ну вот разработка ZoL (именно в Linux) оплачивается какой-то большой и толстой конторой. И как, хорошо?
>> ну какая ж она большая и толстая - сравни с орацлом или даже саном времен его заката.
> По сравнению с ними не толстая, да.redhat покупается ibm... получается linux одномоментно становится в 20 раз длиннее и в 5 толще?
может стоит оставить замеры анальных зондов специалисту выше?
к сожалению для любителей zfs, редхат уже купил другие наработки, подорого, поэтому не надейтесь что они передумают. У вас будет xfs over lvm(lite, хм) - с собственной реализацией всех ключевых идей - и дедапа, и сжатия, и trim, и дублирования данных - на блочном уровне вместо уровня fs.На все деньги теперь и ibm, ага.
> может стоит оставить замеры анальных зондов специалисту выше?
да чего их мерять, действительно - нагибайся и раздвигай, введут такой, который оказался нужен бизнесу, а не такой как ты себе отмерял.
>> Ну вот разработка ZoL (именно в Linux) оплачивается какой-то большой и толстой конторой. И как,
>> хорошо?
> ну какая ж она большая и толстаяПодумаешь, протухли стратегические запасы нефти -- это не делает Министерство энергетики США банкротом. У них бездонный кредит доверия, станок и лобби на Опеннете.
Такое сальто-мортале по втаскиванию политоты впечатляет.
>а вот два (или три) основных коммитера нынешей zfs с Украины (коммиты от людей, выдающих себя сейчас за "отцов проекта" там в лупу не разглядеть) - видимо, пойдут на мороз.Ага, при этом один сидит на фоундейшен деньги, второй в той же iX. Уже собираются на мороз.
сложно сказать.. а большие это насколько? 10P-20P - это большая или не очень ?
А там тож линукс валяется.. правда с ext4.
> А там тож линукс валяется.. правда с ext4.вам эти данные вообще, видимо, не нужны?
(про бэкап не спрашиваю, восстановление закончится с тепловой смертью вселенной)
P.S. интересно, сколько там выполняется fsck, сколько при этом требуется памяти и выполняли ли это хотя бы один раз
Когда уже перейдут на ядро Linux?
не торопите события. Щас вот kms докопипастили, теперь докопипастят zol, останется выпилить слишком хорошо работающий ipsec и больше преимуществ не останется, можно докрашивать и выбрасывать остальное (а то оно плохо совместимо с systemd, а без него гом какой-то вялый).
> слишком хорошо работающий ipsecБУГАГА !!!! Хорошо работающий ipsec, хорошая шутка.
Ващето linuxkpi юзается не только для дров на видюхи но и для дров некоторых сетевух.
С другой стороны из того что реально лучше и проще выкинуть и втащить с линукса - вифи, ибо во фре только 2,4n.
А дальше выкидывать ничего смысла нет, остальное прекрасно работает, линуксятники пусть дальше пилят дрова а во фрю их на шару забирать будут.
еще бы упраление питанием стыбрили бы и работу с USB3/sd
а то под фрей ноут постоянно гудел с включенным поверд. Поставил бубунту лтс - тишина без каких-либо настроек.Печально все это. Теперь фришка в виртаулочке крутится. А бубунта бубунтит.
Хотя одно меня удивило. ПОд фрей амдшные драйера работали на ура, окромя 3д разве что. Фурифокс казал котиков на ютюбчике без тиринга и особой нарузки под цпу. Под бубунтой сразу напрягается одно ядро, а под ксубунтой впервый за долгие годы увидел тиринг даже при простом браузинге. Жесть.
> Когда уже перейдут на ядро Linux?Когда в этом будет хоть какой то смысл.
>> Когда уже перейдут на ядро Linux?
> Когда в этом будет хоть какой то смысл.Нет, когда ZOG ^W Микрософт скажет, что GPLv2== уже окончательный пермиссив, и Джим Землин подтвердит и проаплодирует.
Отличная новость. Когда-то бсдшники хвастались, что у них есть zfs "подаренная" Sun'ом. Через 11 лет они перешли на реализацию zfs написанную для linux!
так а ZoL кто zfs "подарил"? )))
> Отличная новость. Когда-то бсдшники хвастались, что у них есть zfs "подаренная" Sun'ом. Через 11 лет они перешли на реализацию zfs написанную для linux!Так сформулированно, как будто чуть ли не каждый (опеннетный) пользователь линукса лично, в поте лица, писал часть кода для ZoL, вместо комментирования "нинужно! Какаха! У нас есть Btrfs!".
Кстати, реальные причины в оригинальной формулировке:
https://lists.freebsd.org/pipermail/freebsd-current/2018-Dec...
> FreeBSD has regularly pulled changes from Illumos and tried to push back any bug fixes and new features done in the context of FreeBSD.
> In the past few years the vast majority of new development in ZFS has taken place in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced that they will be moving to ZoL
> I have also discovered that many races and locking bugs have been fixed in ZoL and never made it back to Illumos and thus FreeBSD.В общем, OpenZFS не взлетел, кооперироваться стало не с кем, ZoLеры обратно в общий пул коммитить как бы с самого начала не собирались - видимо в "Lawrence Livermore National Laboratory" на это гранты не выдают.
Радуйтесь, может теперь в эту вашу "superior to BSD" раелизацию хоть TRIM завезут.
> Радуйтесь, может теперь в эту вашу "superior to BSD" раелизацию хоть TRIM завезут.как я понимаю, ровно наоборот - теперь ее нет и в bsd.
Ну, то есть пока ее нет в экспериментальных портах, которые еще не факт что подменят когда либо основные модули в ядре, но звоночек уже прозвенел.
Походу зфс всё ( Зато "щифрование" завези.
Ну, если ZFS для тебя это всё, я могу тебя только поздравить. Расти бАльшой.
шифрование через geli в общем-то работало и до того (да, поверх него можно было создать zfs и такой вариант работоспособен...в тех же пределах что обычная zfs)
Без странности от дельфикса, ради которой, если кто не заметил, искалечено громадное количество не трогавшегося со времен сана кода, я бы, пожалуй, предпочел пережить.
>шифрование через geli в общем-то работало и до того (да, поверх него можно было создать zfs и такой вариант работоспособен...в тех же пределах что обычная zfs)Я так и делал...
>Без странности от дельфикса, ради которой, если кто не заметил, искалечено громадное количество не трогавшегося со времен сана кода, я бы, пожалуй, предпочел пережить.Но у них шилов одном месте.
Шифрование на уровне фс намного интереснее.
ну нет, оно оставляет снаружи слишком много данных - перечитай результат аудита encfs, подумай, что из этого "на уровне fs" тоже останется, и каких еще лишних сведений получит атакующий.Я понимаю еще, если б ты сказал что geli+zfs (в ее bsd-версии) вряд ли работает эффективно (хотя мне доказывали, что да - но как-то малоубедительно)
В первую очередь, шифрование интересно с точки зрения передачи потом зашифрованной версисе в какой-нибудь облачный сервис хранения резервных копий через zfs send.Даже не само шифрование zfs или zvol. А было бы здорово иметь возможность шифровать на лету при операции zfs send, чтобы передающийся поток был зашифрованным. Это позволит не опасаться компрометации данных со стороны облачного сервиса и в то же время воспользоваться всеми преимуществами дифференциального send-receive
Кто поставил - это каменту? Аргументы будут?
RAIDZ В ZFSonLinux на механических накопителях большая попоболь. Говорю, как пользователь. И только лишь в zfsonlinux 8.0 планируются нововведения которые позволят теоретически сделать resilving zpool содержащий, raidz vdev из дисков 8ТБ не за 2 месяца (если повезет, а то и пол года-год! Харды умрут а оно так и не доделается), а за 10-20 часов, как это и должно быть.Сейчас оно проверяет данные, проигрывая их в порядке совершения транзакций, рождая огромный поток случайного чтения. М одного vdev из 5 дисков по 8TB снимается от 50 до 1000 iops и скорость соответственно в сотни килобайт в секунду при объеме vdev 32ТБ!
> Походу зфс всё (А что, другие ОС в вашу вселенную не завезли?
Теперь есть общая реализация иtrim для всех. В zol заехалала месяц назад.
> Радуйтесь, может теперь в эту вашу "superior to BSD" раелизацию хоть TRIM
> завезут.Будьте в теме.
zfs-0.8.0-rc4
New Features
Native encryption
Device removal
Allocation classes
Pool checkpoints
Sequential scrub and resilver
Project quota
Channel programs
Direct IO
Deferred resilvers
Pool initialization
pyzfs python3 compatibility
Pool TRIM*https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.8.0-rc4
> Будьте в теме.
> zfs-0.8.0-rc4
> released this Apr 17, 2019А теперь внимание на мелкий шрифт:
> Contributions-by: Saso Kiselkov <saso.kiselkov@nexenta.com>
> Contributions-by: Tim Chase <tim@chase2k.com>
> Contributions-by: Chunwei Chen <tuxoko@gmail.com>Смотрит в ZoB:
% grep -R Kiselkov /usr/src/sys/cddl
/usr/src/sys/cddl/boot/zfs/zfsimpl.h: * Copyright 2013 by Saso Kiselkov. All rights reserved.
/usr/src/sys/cddl/boot/zfs/sha256.c: * Copyright 2013 Saso Kiselkov. All rights reserved.
/usr/src/sys/cddl/boot/zfs/skein_zfs.c: * Copyright 2013 Saso Kiselkov. All rights reserved.еще 100500 строк
% grep -R Chunwei /usr/src/sys/cddl
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/abd.h: * Copyright (c) 2014 by Chunwei Chen. All rights reserved.
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c: * Copyright (c) 2015 Chunwei Chen. All rights reserved.
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c: * Copyright (c) 2014 by Chunwei Chen. All rights reserved.
О чем и речь ;)
> Смотрит в ZoB:
> % grep -R Kiselkov /usr/src/sys/cddlЗабыл добавить:
> % uname -rs
> FreeBSD 12.0-STABLE
>> Будьте в теме.
>> zfs-0.8.0-rc4
>> released this Apr 17, 2019
> А теперь внимание на мелкий шрифт:
>> Contributions-by: Saso Kiselkov <saso.kiselkov@nexenta.com>
>> Contributions-by: Tim Chase <tim@chase2k.com>
>> Contributions-by: Chunwei Chen <tuxoko@gmail.com>Что-то шибко мелко, в https://github.com/zfsonlinux/zfs/blob/master/AUTHORS контрибьюторов 300 персон.
> Смотрит в ZoB: ]
> % grep -R Kiselkov /usr/src/sys/cddl
> /usr/src/sys/cddl/boot/zfs/zfsimpl.h: * Copyright 2013 by Saso Kiselkov. All rights reserved.
> /usr/src/sys/cddl/boot/zfs/sha256.c: * Copyright 2013 Saso Kiselkov. All rights reserved.
> /usr/src/sys/cddl/boot/zfs/skein_zfs.c: * Copyright 2013 Saso Kiselkov. All rights reserved.В Illumos смотреть не надо?
И к Tim Chase https://github.com/dweeezil/zfs не надо?https://github.com/zfsonlinux/zfs/pull/8255
This is a port of Nextenta's TRIM support to the current master branch - post-device removal and post-device initialization.
> еще 100500 строк
> % grep -R Chunwei /usr/src/sys/cddl
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/abd.h: * Copyright
> (c) 2014 by Chunwei Chen. All rights reserved.
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c: * Copyright
> (c) 2015 Chunwei Chen. All rights reserved.
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c: * Copyright (c) 2014
> by Chunwei Chen. All rights reserved.
>
> О чем и речь ;)Была -- внезапно -- о "завезут". ;))
> Что-то шибко мелко, в https://github.com/zfsonlinux/zfs/blob/master/AUTHORS контрибьюторов 300 персон.А зачем на те 300 персон, когда есть конкретный коммит?
https://github.com/zfsonlinux/zfs/commit/1b939560be5c51deecf...
> Add TRIM support
> UNMAP/TRIM support is a frequently-requested feature to help
> Reviewed-by: Serapheim Dimitropoulos <serapheim@delphix.com>
> Contributions-by: Saso Kiselkov <saso.kiselkov@nexenta.com>
> Contributions-by: Tim Chase <tim@chase2k.com>
> Contributions-by: Chunwei Chen <tuxoko@gmail.com>
> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>/
/
> В Illumos смотреть не надо?
> И к Tim Chase https://github.com/dweeezil/zfs не надо?
> https://github.com/zfsonlinux/zfs/pull/8255
> This is a port of Nextenta's TRIM support to the current master
> branch - post-device removal and post-device initialization.Разрешаю не смотреть! И к Тиму не ходить - я уже понял, что хотя попыток вкоммитить TRIM была далеко не одна
https://github.com/zfsonlinux/zfs/pulls?q=is:pr+trim+is:closed
> Add TRIM support - replaces #5925 and #7363 Status: Code Review Needed Type: Feature
> OpenZFS - 6363 Add UNMAP/TRIM functionality (v2) Status: Inactive Status: Revision Needed Type: Feature
> #7363 by tuxoko was closed Jan 8, 2019 • Review required 0 of 13/
> OpenZFS - 6363 Add UNMAP/TRIM functionality Status: Revision Needed Type: Feature/
> TRIM/Discard support from Nexenta Type: Feature
> #3656 by dweeezil was closed Mar 25, 2017 • Changes requested 0.7.0/
> TRIM/UNMAP/DISCARD support for vdevs (2) Component: ZVOL
> #1016 by dechamps was closed Jan 12, 2016 • Review required 0.7.0/
> TRIM/UNMAP/DISCARD support for vdevs
> #924 by dechamps was closed Oct 5, 2012 • Review requiredпоявление поддержки в RC сразу чере пару месяцев после присоединения ZoB, как и мелькание определенных имен в контрибутах - просто такие совпадения ;)
> Была -- внезапно -- о "завезут". ;))Ну уел-уел, на три дня, да еще и в RC ;)
> в эту вашу "superior to BSD" раелизацию хоть TRIM завезутТам-то она есть как раз. В отличие от ZoL.
>> в эту вашу "superior to BSD" раелизацию хоть TRIM завезут
> Там-то она есть как раз. В отличие от ZoL.Superior to sth. == превосходство над чем-то.
Или?
>>> в эту вашу "superior to BSD" раелизацию хоть TRIM завезут
>> Там-то она есть как раз. В отличие от ZoL.
> Superior to sth. == превосходство над чем-то.
> Или?Угу, я что-то в глаза пое..^Wполюбился. Отвечал, подразумевая, что оппонент считает, что в FreeBSD этого не было, а теперь будет.
>В общем, OpenZFS не взлетелНаоборот, взлетел и теперь на основе кодовой базы ZoL.
>ZoLеры обратно в общий пул коммитить как бы с самого начала не собирались
Коммитили, но скорость развития в илюмос гейт не радует.
>Радуйтесь, может теперь в эту вашу "superior to BSD" раелизацию хоть TRIM завезут.
В FreeBSD TRIM самыми первыми хавезли. В илюмос появилась альтернативная реализация.
Букавально в прошлом месяце в ZoL заехала версия из илюмос и теперь TRIM будет одинаковый и у всех.
>>В общем, OpenZFS не взлетел
> Наоборот, взлетел и теперь на основе кодовой базы ZoL.Только "нызенко-нызенко".
>>ZoLеры обратно в общий пул коммитить как бы с самого начала не собирались
> Коммитили, но скорость развития в илюмос гейт не радует.Возможно что коммитили, но повторю аргумент разраба:
> I have also discovered that many races and locking bugs have been fixed in ZoL and never made it back to Illumos and thus FreeBSD.
>>Радуйтесь, может теперь в эту вашу "superior to BSD" раелизацию хоть TRIM завезут.
> В FreeBSD TRIM самыми первыми хавезли. В илюмос появилась альтернативная реализация.
> Букавально в прошлом месяце в ZoL заехала версия из илюмос и теперь
> TRIM будет одинаковый и у всех.Я в курсе, Кэп (имелось в виду "превосходящая BSD реализацию" - т.е. ZoL).
Теперь посмотрите внимательно на имена в "contributions by"
https://github.com/zfsonlinux/zfs/commit/1b939560be5c51deecf...
;)
> Отличная новость. Когда-то бсдшники хвастались, что у них есть zfs "подаренная" Sun'ом.
> Через 11 лет они перешли на реализацию zfs написанную для linux!Маркетинг с "новыми рюшечками" победил здравый смысл.
Следующий этап - тестирование сборок, переведённых на ядро Linux. Oh shi...
> Следующий этап - тестирование сборок, переведённых на ядро Linux.В смысле, вот так:
https://www.debian.org/ports/kfreebsd-gnu/
https://wiki.gentoo.org/wiki/Gentoo_FreeBSD
> a Gentoo system based on the FreeBSD kernel
> Oh shi...
А какой ныне в этом смысл, если в бздшном ядре и около не осталось ничего интересного?
А что интересного в ведре lинукс? Дырявые "контейнеры"?
В linux огромное кол-во типов контейнеров поддерживается. Хочешь, выбирай дырявый, хочешь - не дырявый. О котором из них ты сейчас? А сколько "не дырявых" контейнеров поддерживается в FreeBSD?
> А сколько "не дырявых" контейнеров поддерживается в FreeBSD?Недырявые джайлы.
>В linux огромное кол-во типов контейнеров поддерживается.
Нормалные толко опенвз, но они не ко двору рэдхэт. Кстати перечисл бы осталные.
> Нормалные толко опенвз, но они не ко двору рэдхэт.Нет, тут дело не в шляпе. А в "болотниках" вроде Димы Монахова.
Лучше эту тему не развивать, но разница причин слишком важная.
>> Нормалные толко опенвз, но они не ко двору рэдхэт.
> Нет, тут дело не в шляпе. А в "болотниках" вроде Димы
> Монахова.Сами опенвз похужали от того, что кто-то "болотник"?
> Сами опенвз похужалиНе то слово. Довольно трудно быть живым проектом, когда у тебя взяли и спёрли душу и пламенный мотор -- люди-то тоже эксплойтятся.
Серёжка Бронников пытался подхватить на ту же высоту, но всё-таки оказалось не по силам :-(
>> Нормалные толко опенвз, но они не ко двору рэдхэт.
> Нет, тут дело не в шляпе. А в "болотниках" вроде Димы
> Монахова.
> Лучше эту тему не развивать, но разница причин слишком важная.а почитать есть где, а то я не в теме?
>> А сколько "не дырявых" контейнеров поддерживается в FreeBSD?
> Недырявые джайлы.
>>В linux огромное кол-во типов контейнеров поддерживается.
> Нормалные толко опенвз, но они не ко двору рэдхэт. Кстати перечисл бы
> осталные.Я вот использую systemd-nspawn, меня вполне устраивают. Ну да-да, systemd и всё такое... сейчас начнётся старая песня. Но они реально удобные и простые.
> Я вот использую systemd-nspawn, меня вполне устраивают. Ну да-да, systemd и всё
> такое... сейчас начнётся старая песня. Но они реально удобные и простые.покажи аналог jail -l -n shit-program -s 2 /var/chroot hostname ${MY_IP} /usr/local/sbin/shit-program args
(да, я знаю что такой синтаксис немодный - нас - рать, авторам нового модного желаю попасть в рай, ну или сдохнуть - побыстрее, пока поменьше вокруг себя изгадили)да, это можно запустить прямо из шелла, если захотелось посмотреть,как вот с этими параметрами сработает, а не писать простыню текстового файла с нескучным синтаксисом и результат запуска потом искать в нескучных бинарных логах.
вот это - удобно и просто. В отличие от сцыстем-де поделки.
systemd-nspawn -M shit-program -D /var/chroot /usr/local/sbin/shit-program argsНе благодари.
> systemd-nspawn -M shit-program -D /var/chroot /usr/local/sbin/shit-program args
> Не благодари.За что?
https://manpages.debian.org/jessie/systemd/systemd-nspawn.1....
> Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups.
> Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container.
> The intended use of this program is debugging and testing as well as building of packages, distributions and software involved with boot and systems management.
не вижу здесь привязок сетевых интерфейсов (нет, не надо все, надо конкретные, у меня они явно перечислены) и ограничений того, что можно, а что нельзя делать внутри контейнера. Гвоздиком прибито и не управляется, да?и да, обратите внимание - сетевой интерфейс хоста при таком запуске никуда не девается, это ни разу не аналог --network-interface= (так тоже можно, но обычно совершенно не это нужно)
и так у вас все - задачу наполовину не поняли, из понятого - сделали ровно половину. Хотя, чисто теоретически, ничего не мешало сделать все - но, как обычно, разработчики уже задрав хвосты убежали за новой целью, бросив предыдущую игрушку полудоделанной.
так вы тоже не можете: jail / /someprogram - нет, не надо мне тут оверрайдить /dev, он мне нужен.
системд, конечно, мда... но фрибздешников пинать тоже очень легко. инклуды в jail.conf? нет, не слышали? пихаем тысячи хостов в один файл.для джейлов с vimage, например, нельзя задать фиксированный мак тамже в конфиге. надо подхачивать.
тот же vimage у вас недавно только стал в составе ядра идти.
> системд, конечно, мда... но фрибздешников пинать тоже очень легко. инклуды в jail.conf? нет, не
> слышали? пихаем тысячи хостов в один файл.если вам нужны тысячи джейлов на одной системе - вы явно делаете что-то не так и совсем не то что планировали разработчики.
вероятно, стоит обратиться к докеру и кубернетесу, они все сделают за вас единственно-правильным образом. Я вот и без jail.conf неплохо обхожусь лет этак десять, и не скажу чтобы очень хотелось им пользоваться и в дальнейшем.то же и с vimage - он больше десяти лет никому не требовался, наоборот, всем было очень удобно что jail - это про изоляцию, а не про виртуальную недомашину. Нескучных виртуалочек у нас и так уже четыре.
>> системд, конечно, мда... но фрибздешников пинать тоже очень легко. инклуды в jail.conf? нет, не
>> слышали? пихаем тысячи хостов в один файл.
> если вам нужны тысячи джейлов на одной системе - вы явно делаете
> что-то не так
>то же и с vimage - он больше десяти лет никому не требовалсяну ес-но. "не нужно". слив засчитан.
> системд, конечно, мда... но фрибздешников пинать тоже очень легко. инклуды в jail.conf? нет, не слышали? пихаем тысячи хостов в один файл.Особенно не разобравшись. jail.conf и прочее - это обвязка, причем легкая (достаточно глянуть в man jail).
Ставим ezjail (тоже нулевые зависимости) и пихаем до упора отдельные конфы в /usr/local/etс/ezjail
или пишем свою портянку с вызовом jail -param1 -param2. Это не LXC обвязка-фреймворк, оно высокоуровненно.> для джейлов с vimage, например, нельзя задать фиксированный мак тамже в конфиге. надо подхачивать.
Можно:
exec.prestart += "/sbin/ifconfig
exec.created += "/sbin/ifconfig> тот же vimage у вас недавно только стал в составе ядра идти.
Ну да, десять лет всего. Свежачок.
Ты путаешь с дефолтным включением в дженерик-ядро.
А кастомное фришное ядро соберется на калькуляторе за 15-30 минут.
> Ставим ezjail (тоже нулевые зависимости) и пихаем до упора отдельные конфы в /usr/local/etс/ezjailно зачем??! почему такой простой вещи нет в базе. в openvz она 10 лет.
> Можно:
можно и в ухе пяткой ковырять. из серии хаков. в openvz задается параметром, поэтому это удобно автоматизировать.
> Ты путаешь с дефолтным включением в дженерик-ядро. А кастомное фришное ядро ...
а кастомное фришное ядро для д*билов (админов локалхоста).
>> Ты путаешь с дефолтным включением в дженерик-ядро. А кастомное фришное ядро ...
> а кастомное фришное ядро для д*билов (админов локалхоста).Ну раз ты так говоришь, то да, это убойный аргумент.
> но зачем??! почему такой простой вещи нет в базе. в openvz она 10 лет.Еще раз:
pkg info -ds ezjail
ezjail-3.4.2_1
Flat size : 118KiB
0 зависимостей, 118 KB размер.
Там еще c полдюжины на любой вкус и цвет наберется, от фреймворка "сделай сам" до "все включено":
https://www.freshports.org/search.php?stype=shortdescription...> можно и в ухе пяткой ковырять. из серии хаков. в openvz задается
> параметром, поэтому это удобно автоматизировать.Ну вам там в пингвин эти базовые вещи и "можно задать одним параметром" Леннарт в Красной Шляпе принес, только что-то не вижу радости, совсем наоборот.
Об этом сейчас мало кто помнит, но в годах эдак 2011-2012-ых линуксоиды кипятком мочились в штаны от того, что у них гипервизор, который позволяет крутить виртуалки, а в этой глупой фре только глупые никому не нужные джайлы.2к19 - линуксоиды поняли, что гипервизор - это слишком большие накладные расходы, и теперь в почете контейнеры, суть - те же джайлы. Но о том, что говорилось по поводу джайлов 7 лет назад, линуксоиды предпочитают тактично не вспоминать.
> 2к19 - линуксоиды поняли, что гипервизор - это слишком большие накладные расходы,а фрибсдшники наконец-то в своем наколенном запилили графическую консоль -правда, зачем-то через эмулятор uefi.
Ну им привычно чесать левое ухо правой пяткой.
В огороде бузина, а в Киеве дядька.
Потому что линуксоиды в большинcтве своем это токсичные лицемеры.
> 2к19 - линуксоиды поняли, что гипервизор - это слишком большие
> накладные расходы, и теперь в почете контейнеры, суть - те же джайлы.Вас ведь правда не затруднит кругом марш читать, в каких годах появились vz, vserver и openvz? Хотя бы чтоб такую феерическую чушь не нести, например.
>> 2к19 - линуксоиды поняли, что гипервизор - это слишком большие
>> накладные расходы, и теперь в почете контейнеры, суть - те же джайлы.
> Вас ведь правда не затруднит кругом марш читать, в каких годах появились
> vz, vserver и openvz? Хотя бы чтоб такую феерическую чушь
> не нести, например.он там, конечно, чушь сморозил, но загвоздка в том, что openvz (в том виде, как я его знал) закончился. застывший (не разрабатываемый) jail сейчас гораздо ближе к тому openvz, чем lxc.
В линукс уже завезли более вменяемый kqueue?
> В линукс уже завезли более вменяемый kqueue?Фуру на таможне задержали.
это не наш кокс!
Просто ты ядро фри не видел.
нетграф, геом, осс (как для юзера), kqueue() - вполне годные вещи.
Есть ещё mac, тоже весьма интересный фреймворк.
Вторая новость подряд довольно тонкий набросец. Автор молодец.
По факту - слияние кодовых баз. Вместо того, чтобы распылять силы на n реализаций по типу "у каждого своя".
> Вторая новость подряд довольно тонкий набросец. Автор молодец.
> По факту - слияние кодовых баз. Вместо того, чтобы распылять силы на
> n реализаций по типу "у каждого своя".Не убивай интригу. Тут уже рубилово, пламя до потолка и с обстрелов вот-вот в штыковую, а ты такой... "А о чём спорить?". Имей совесть. Можешь - набрось, не можешь - наблюдай со стороны :-)
Стагнация и Оракл - это слова-синонимы
а мы тут причем? Вам список изменений за последние два года, криво и плохо (или вообще не) воспроизведенных на коленке в "открытой" версии зачитать вслух, или вы сами способным воспользоваться гуглопоиском?у нас никакой стагнации нет, мы вполне способны развивать сановский проект без вас.
уже все сановские открытые проекты стагнируют(OpenOffice,OpenSolaris,java вкривь пошла,mysql тоже добились, чтобы их форкнули. Всё чего касается Оракл, приходит в запустение
> уже все сановские открытые проекты стагнируют(OpenOffice,OpenSolaris,java вкривь пошла,mysqlповторяем - а мы тут причем? Вам дали - вы и пилите, они золотые.
> тоже добились, чтобы их форкнули. Всё чего касается Оракл, приходит в
> запустениенеправда, у нас прекрасно работает солярис (и в ем zfs с кучей фич, которые вы либо осилили в бета версии, либо неосилили вообще, только у нас еще и работают), орацл-дб, унбрякабл линукс, и вон даже btrfs мы вам почти допилили до почти рабочего состояния.
а вот все, куда мы пустили адептов секты - оно да, пришло в упадок.
> Всё чего касается Оракл, приходит в запустение
> неправда, у нас прекрасно работает солярисХороший анекдот получился.
А он и правда отлично работает. Правда на локалхостах и дешевых серверках его не встретишь, а там где есть, туда в лаптях не пускають.
> Правда на локалхостах и дешевых серверках его не встретишькак будто вам что-то мешает установить?
При попытке запустить его в виртуалки- оно что-то вякнуло невнятное, в духе "ваш процессор слишком ту фаст" и повесилось.
а! виртуалкой-то, небось, bhyve был? ;-)в vcenter "oracle solaris 11" ставишь в настройках - и вполне себе работает. Эх, жаль что ТАКОЕ - даром не нужно.
> оно что-то вякнуло невнятное, в духе "ваш процессор слишком ту фаст" и повесилось.Турбо-паскалем собирали? Нууу, тогда ССЗБ
>В качестве ФС для корневого раздела могут использоваться UFS и ZFS.Древность и монстр.
Оно там через линуксулятор?
Это хорошая новость или плохая? Вот щас FreeNAS делают на FreeBSD, там нативный ZFS. А потом будет ZFS on Linux? Наверняка менее стабильный? Или FreeNAS изменения не коснутся?
коснутся.
более того, именно они их будут пропихивать со всей возможной силой - ибо фринас, кто не в курсе, полигон бетатестирования коммерческого решения iX.
> более того, именно они их будут пропихивать со всей возможной силой -
> ибо фринас, кто не в курсе, полигон бетатестирования коммерческого решения iX.Но разве iX не заинтересован в стабилной бесбажной и надёжной ФС?
iX заинтересован в продажах фигни подорого и минимизации расходов.
он не для того брал халяву, чтоб потом платить денег разработчикам.при этом у них уже есть работающее (и оттестированное нахаляву freenasерами) решение, а их пользователь совершенно не собирается обмазываться свеженьким.
Можно еще десять лет продавать ему freebsd10, пока не станет невозможным в нее бэкпортировать драйвера трех-четырех нужных карточек, большего не требуется, поскольку платформа собственная.Но можно окучить лоха второй раз, если продать ему "апгрейд". Для апгрейда нужны фичи, а не "мы тут перешли на основу freebsd13, го топтать свежие сочные грабли", а с фичами у фрибсды не то что плохо, а вообще никак - даже там где было вообще-то несложно (из четырех, или трех криптохэшей за пять лет героически портировали самый медленный и неэффективный - казалось бы, как этот код может быть солярисозависимым?) Поэтому надо идти туда, где халявы больше, она нажористей и мжвячней. А это на сегодня ZoL, тем более что и дельфикс передает пламенный кревед.
Т.е. они ничего не теряют, если из этого что выгорит - отлично, а нет - ну не получилось, ничего страшного - в конце-концов гляньте верхнее решение iX - и найдите там хоть что-нибудь про zfs и фрю ;-)
А спонсировать серьезную разработку - нееее, этим вон пусть ibm занимается, у него денех многа.
Раньше в *BSD оно просто правильно работало, а теперь будет работать через попу, но зато с новыми спецефектами.
А то! Надо же "менстриму" подмахнут.
>Раньше в *BSD оно просто правильно работалоРаскрой тему, чем это вдруг порт ZoL на фряху отличается от порта с илюмос?
>>Раньше в *BSD оно просто правильно работало
> Раскрой тему, чем это вдруг порт ZoL на фряху отличается от порта
> с илюмос?На скоко знаю вариант для ZFS под Linux имеет проблему в отжырании оперативки под кашу мимо родного механизма дисковой кашы ОС. То есть ОС видит это всё как прогаму (точнее память програмы). Поправте если шото поменялось.
В *BSD же этой проблемы нет, там каша ZFS для ОС видна именно как дисковая каша. Но теперь костыль из Linux портирован и на *BSD. УРА!
>В *BSD же этой проблемы нетТак её и в порте ZoL не будет. Там под каждую ОС пилится свой слой совместимости.
Во фре это почти один в один со старым портом из илюмос.
> Так её и в порте ZoL не будет. Там под каждую ОС пилится свой слой совместимости.вы там посмотрите в код (bsd'шный) - и убедитесь, что "слой совместимости" - он буквально ни о чем.
По факту там #ifdef illumos через каждые десять строк, о чем громко плачут и линуксеры, и все остальные.
А тех кто пытается решать эту проблему вместо загоняния под коврик, дико не любят, ага.Потому что одно дело пару примитивных врапперов нашлепать, а совсем другое - когда в ядре вообще нет нужного механизма, а чтобы он появился, надо затронуть кучу других мест в самых нехороших и опасных частях ядра. Причем если фрибсдшникам в теории это сделать можно, лишь бы ничего другим не сломать, то у линуксеров мертвым бетонным блоком поперек лежит Линус, который не позволит ни одного изменения в ядре, кроме тривиальных багфиксов или оплаченных кем надо. Где там, говорите, ваш вайргад? Ага, все там же - "порежьте помельче, переформатируйте, и с поклоном подайте заново - мы снова понюхаем, недовольно кривим рожу и выбросим ваш труд в помойку". Но некоторые люди необучаемы в принципе.
> В *BSD же этой проблемы нет, там каша ZFS для ОС видна именно как дисковая каша.это называется "zones", и с ними на самом деле не все хорошо - они принадлежат конкретной подсистеме (не абстрактному "диску", а конкретно zfs, ufs не сможет задействовать чанк из нее).
Краткий пересказ slw: чтобы освободить память внутри - достаточно пометить ее как свободную. Чтобы вернуть эту память операционной системе - здравствуй global lock и медленный вызов с обновлениями кучи таблиц - а память-то может быть системе в этот момент и вовсе даже не нужна (а вот под кэш нужна и через сто наносекунд мы ее обратно запросим)!поэтому есть специальный костыль имени сана (видимо, там примерно так же, а врали-то, врали, что чистая сыстемV еще с 94го года!) тщательно выпиленный неосиляторами из iX и около. Патч, возвращающий его на место принимать отказались по куче причин. Причина первая - он не украинский!
Если что - в сетевых буферах в этот же момент может еще пара гигабайт "свободной" памяти лежать - вам ее тоже никто не вернет.
но данный порт ничуточки эту проблему решать не собирается, более того, известные методы ее если не обхода то уменьшения объема - с ним не сработают.
Может хоть протестят нормально, прежде чем внедрять?
ну вот на фринасерах и потестят. А ты думал, у нас есть какое-то другое тестирование?(нет, никто тебе не мешает, конечно, скачать вот это, которое выкатили, или самому в работающей системе обновиться на портовую версию (nextboot если што - наше всьо) - но ты ж не захочешь?)
Это безусловно хорошая новость. Пострадают только лишь нетакие как все, а именно те кто срёт кирпичами от слова LINUX.OpenZFS переезжает на кодовую базу ZoL и это случившийся факт. Теперь под все системы будут пилить именно в репе ZoL'а. А это и фря и илюмос, и линукс, и винда, и макось.
Но это не значит, что родовые проблемы каждой операционки внезапно исчезнут.
Поэтому как ZFS криво работала под линуксом, так и продолжит. Как была она прикручена сбоку к фряхе, так и будет.
Хочу просто напомнить что от RHEL есть опенсорцное решение для сжатия и дедупликации на уровне блочного устройства, без этих ваших ZoL...
Хочу напомнить, что OpenZFS чисто опенсорсное решение.
Тоже попенсорц https://github.com/dm-vdo
ну вот и прикиньте его эффективность - без информации о том, данные ли это вообще, без подгона размера блока под блок fs и под блоки с которыми работает прикладная программа и т д.
Добавьте теперь fsync() ;-)Честно-то говоря, то и другое и в ZFS (без всяких ваших ZoL) очень сомнительные нововведения (у первого кривой и скорее всего багнутый код, вызывающий жор памяти, cpu, и дидлоки, у второго . кривой и вполне возможно - багнутый код, вызывающий неимоверный жор памяти - тут, правда, некоторые ентер-прайс решения внезапно идут вровень ;)
это не zfs, там свой уровень для этого, где размер блока известен. а самое главное, это все интегрировано с VM подсистемой ОС. в отличие от ARC.
Как человеку, которому приходится использовать ZFS on Linux в Proxmox, доложу, что ZoL нещадно тормозит на all-flash пулах, не может в IO scheduler, в результате - read/write amplification на записи в 8-10 раз.
Под LVM2 - 256k IOPS, а на zvol - 60k IOPS (и загрузка проца). Что бы я не далал с параметрами модуля - бесполезно. Во FreeBSD ZFS работает отлично.
Недавно в голову пришла идея, пробросить через PCI passthrough виртуалку с фрей NVME и VF от Mellanox ConnectX-3, и, собрав SPDK как-то наладить NVMEoF target через RDMA обратно в Proxmox.
И тут такая новость.Просто офигеть.
> ZoL нещадно тормозит на all-flash пулахкак будто она на других не тормозит. Просто на фоне тормозов диска это не так заметно.
> не может в IO scheduler,
который из? У нас в каждой новой версии новый. Вот, например, blk-mq ;-)
> Недавно в голову пришла идея, пробросить через PCI passthrough виртуалку с фрей
> NVME и VF от Mellanox ConnectX-3, и, собрав SPDK как-то наладить
> NVMEoF target через RDMA обратно в Proxmox.ну расскажите, что намеряете. Я даже готов задонейтить исследование мелкой суммой.
> И тут такая новость.Просто офигеть.
оно еще не завтра настанет окончательно.
> как будто она на других не тормозит. Просто на фоне тормозов диска это не так заметно.Просто на NVME пуле это вызавает особенный баттхерт. С 50-80% потерей IOPS и 10-15 load average чисто при запуске fio 16 тредов с очередью 16 смириться не могу, но мне нужны снэпшоты на zvol и инкрементальные пересылки. Средствами qemu/proxmox переопределить sector size на паравиртуализованном SCSI не могу.А могу на SCST loopback и через scsi passthrough.
> ну расскажите, что намеряете. Я даже готов задонейтить исследование мелкой суммой.Я пока намерял на NVMEoF target из линуксового ядра, что проброс LVM2 тома с его помошью, через QDR IB в виртуалку на другом хосте совершенно ничтожно влияет на IOPS и загрузку проца на всех элементах этой схемы shared storage. Надо протестировать SPDK и пилить плагин к проксмоксу по образу и подобию ISCSI/DRBD etc. Очевидный недостаток: в проксмокс иди надо впиливать всежий QEMU с NVME патчами, или расстаться с онлайн миграйцией, потому что виртуалки с PCI passthrough устройствами не мигруруют. Можно как-то накостылить ROcE на virtio_net+multipath+pci device hot add/remove но надо ли это ?
> который из? У нас в каждой новой версии новый. Вот, например, blk-mq ;-)Любой. В ZoL тупо не работает скедулер в данный момент. Начинаешь писать на zfs/zvol блоком отличным от recordsize получаешь амплификацию 10 раз на конечном блокдевайсе.
На ихнем гитлабе один страдалец предлагал баунти то ли 3к то ли 5к чтобы починили. Все очень плохо.
Сломали толи в 0.6.4 толи в 0.6.5
Чую, что в 0.8 все будет сломано окончательно.
от оно чо...
То-то я удивлялся некоторым фифектам... надо будет попробовать перенести всю помойку на фрю, благо она виртуальная и это за пятнадцать минут делается, не трогая пула.P.S. у нас же recordsize давно отменили, при включенном сжатии он произвольный?
Результатом опыта не поделишься?
делюсь: epic failstatus: The pool can only be accessed in read-only mode on this system. It
cannot be accessed in read-write mode because it uses the following
feature(s) not supported on this system:
org.zfsonlinux:userobj_accounting (User/Group object accounting.)
(еще одно ненужное ненужно, которое тоже вполне может оказаться причиной тормозов)сам пул, к сожалению, не 100% ненужно, поэтому последовать прекрасному совету не получится.
ну то есть вот так влоб на халяву подключить к чужой системе не выйдет, а если этого не делать, результат теста непонятно как интепретировать.
> P.S. у нас же recordsize давно отменили, при включенном сжатии он произвольный?NVME и особенно всякие оптаны слишком шустрые для сжатия.ARC compression тоже мешает, будучи включенным, проводит время в каких-то непонятных локах. При выключении - крэши.
>> И тут такая новость.Просто офигеть.
> оно еще не завтра настанет окончательно.вот надо на этом тестировании им туда результаты с amplification и заслать. у меня просто не на чем это все проводить. я к фре только присматриваюсь.
надо чем-то тестировать -а у меня как раз старательно blocksize подогнан под используемый базой, и он там не variable.
Но вот идею подменить диск с ос я, пожалуй, попробую, по идее там не должно ничего сломаться от такого фокуса.(хм, да, при первой же попытке "сломалась" freebsd. fetch unknown reloacation type in PLT - похоже, vmdk на их сайте собран переоптимизированным, или просто битый - так падает все, как-то связанное с openssl. И вот так у нас все - за что ни схватись.)
> просто битый - так падает все, как-то связанное с openssl. И
> вот так у нас все - за что ни схватись.)ну как у вас я в общем-то знаю, потому что с четвертого или пятого релиза что-нибудь пытаюсь сделать и что-нибудь падает. вопреки утверждениям фанатиков. но из-за systemd rush я из принципа уже начала что-то на фри переводить... так что новость вызывает смешанные впечатления.
> ну как у вас я в общем-то знаю, потому что с четвертого
> или пятого релиза что-нибудь пытаюсь сделать и что-нибудь падает. вопреки утверждениям фанатиков.Угу. Видели-с. Это ведь у тебя (и только у тебя) "настройки репозиториев не принимают порт" в URL?
о, анонимный фанатик. они принимают порт, но отладочная инфа криво выводится:DBG(1)[2342]> Fetch: fetching from: http://XXX.XXX.XXX.XXX/f12-default/packagesite.txz with opts "i"
это отладка для репозитория на кастомном порту. удивись.
> о, анонимный фанатик. они принимают порт, но отладочная инфа криво выводится:
> DBG(1)[2342]> Fetch: fetching from: http://XXX.XXX.XXX.XXX/f12-default/packagesite.txzтак ты SRV наконец-то отключил?
https://www.opennet.me/openforum/vsluhforumID3/116918.html#123
> crypt
> ну настройки репозиториев не принимают порт в урлТы продолжай, продолжай, особенно про фанатиков.
Можете потестировать свежие сборки фри, о которых говорится в новости?
Интересно стало.
у него проксмокс, он уже знает про zol все что совершенно не хотел спросить.
И тестировать то же самое но в профиль смысла никакого - смысл потестировать старую реализацию, которую пока еще никто не собирается выпиливать - он, вообще-то, есть.
Я не совсем понял, что вы хотели мне сказать.
В профиль/не профиль, но в этих сборках могли чего-нибудь допилить для улучшения совместимости.
Поэтому интересно, будет ли этот ZoL во фри приводить к амплификации иопсов на флэше или нет.
https://www.phoronix.com/scan.php?page=article&item=freebsd-...
> И тут такая новость.Просто офигеть.вот и надо эти тесты на этапе тестирования отправить. не будут они переходить при такой просадке.
Посмотри тесты на форониксhttps://www.phoronix.com/scan.php?page=article&item=freebsd-...
Использование векторных процессорных инструкций выпелено из ядер 5.0+
Вот кстати и в связи с этим будущее самого ZoL довольно туманно, Линус довольно четко сказал куда пойти всем ZoL'овцам. Так что еще возможно что все откатится назад..
теоретически это им несколько отдельных комитов откатить - или обтыкать ifndef __LINUS_SUXX - чтобы фича типа была, но пока вы на подсосе у Линуса - не работала.На остальные особенности не влияет.
Но на практике, да - нахрен нужен такой апстрим, который завтра необратимо сломают, потому что ебеме заслало очередной транш (или орацл, впрочем, какая разница) и вообще stable cpu instruction set is nonsense - завтра запретим использовать ADD, исключительно SUB оставим - просто потому что захотелось.Лучше уж с маководами синхронизироваться - у тех, хотя бы, идитии меньше.
НЕТ.
И не просите.
Я не буду пользоваться фрибсд.СПА-СИ-БО.
DragonflyBSD наше все. Там все свое