После полутора лет разработки состоялся релиз проекта OpenZFS 2.0, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Проект получил известность как "ZFS on Linux" и ранее ограничивался разработкой модуля для ядра Linux, но после переноса поддержки FreeBSD был признан основной реализацией OpenZFS и был избавлен от упоминания Linux в названии. Вся активность по разработке ZFS для Linux и BSD-систем теперь сосредоточена в одном проекте и развивается в общем репозитории...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54172
> Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.И это под открытой лицензией — красота же! Фактический показатель важности открытого ПО в современном мире.
Ну так открытый сфот используют вы науке, как и открытое железо, в космос пускают.
В нынешних условиях это единственно возможная модель эволюции методологии программирования.
Или вскрой исходники, или умри, в судах и корчах полицейской системыю
>под свободной лицензией CDDLПод правильной и истинно свободной, заметьте, в отличие от вредного и ведущего опенсорс к забвению GPL.
>Под правильной и истинно свободной, заметьте, в отличие от вредного и ведущего опенсорс к забвению GPL.Минус тебе толстый тролль. Великий Столлман подарил нам истинную Свободу в виде копилефта!
>Великий Столлман подарил нам истинную Свободу в виде копилефта!Ну так CDDL тоже копилефт. Просто один копилефт с другим не совместим ;)
Так сан хотел солярис проталкивать в пику линуксу. Но получилось иначе.
И в чём он троллит? GPL - рак, дающий метастазы в другие проекты. GPL запрещает использование других, свободных лицензий. И речь не про CDDL даже, а про абсолютно любую лицензию. Пишешь наработки в проекте с GPL и обязан лицензировать в GPL.
все верно, жпл или смерть
GPL -- неудобная лицензия. Она вмешивается в другие лицензии. И тут надо понимать -- в условиях капитализма -- GPL раковая опухоль. В условиях общества совместного справедливого потребления -- GPL является антибиотиком.
> После полутора лет разработки состоялся релиз проекта OpenZFS 2.0не понял с какого момента считать =)
https://en.wikipedia.org/wiki/OpenZFS -- 2013 / 7 лет
0.7.13 -- 4 марта 2019 / 21 месяц
0.8.5 -- 5 октября 2020 / 2 месяца
С 0.8.0.
Яджва года ждал!!!
Ура.
А, если кроме шуток, то я очень рад тому, что ZFS продолжает развиваться, и не томится в экосистеме Oracle.
Ещё бы перелицензировать её так, чтобы можно было в ядро поместить...
И не надо фантазировать на тему "единственной файловой системы для всего"! Для разных задач - разные инструменты.
> И не надо фантазировать на тему "единственной файловой системы для всего"А кто фантазирует-то?) Разве что какие-нибудь романтики-утописты.
Почему? Скажу как фанат ext4 - "единственной файловой системы для всего".
В прошлом году очень много было исправлений read-range-locks для ZFS. Теперь на ней можно вращать даже базы данных, для чего она ранее не была предназначена. Так что ZFS с недавнего времени тоже может быть "единственной файловой системы для всего", если ты захочешь так сделать.
То есть уже ZFS - это ФС общего назначения.
С подобной гибкостью по ее конфигурированию - какие уж тут фантазии? Если среди файловых систем и существует "серебряная пуля", то это она самая и есть.
Ну сконфигурируй её под вчерашний dwarFS.
Сможешь - возьму к себе на работу за меметичные 300к/наносекунду.
"Дай человеку молоток и он везде начнет видеть гвозди"
я смогу, но я уже получаю 300к/наносекунду и к тебе на работу врядли пойду, ЛОЛ!
Теперь поцелуйтесь.
Пруфов конечно не будет
питон только и может что лог с такой скоростью срать
Ну, а что там конфигурировать? Отключить дублирующие фичи и размер блока подобрать.ZFS кстати основные фичи двара сама имеет. Двар наверное оптимизирован на меньший жор ОЗУ, но нужно смотреть.
А какого рода работу вы можете предложить? И в каком виде вам конфигурацию ZFS прислать?
>Ещё бы перелицензировать еёСами кушайте свой GPL, да не обляпайтесь. А адекватные разработчики систем и компании держатся от GPL-кода на социальной дистанции.
Адекватные разработчики берут прежде всего наиболее функциональный и рабочий код. А лицензия - дело второстепенное. Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?
То-то все крупные проекты, не затрагивающие напрямую GPL код используют Apache и BSD. Что мешало, к примеру, Clang под GPL выпустить или Golang, Rust и прочее, что написали крупные компании не так давно?
> То-то все крупные проекты, не затрагивающие напрямую GPL код используют Apache и
> BSD. Что мешало, к примеру, Clang под GPL выпустить или Golang,
> Rust и прочее, что написали крупные компании не так давно?Компиляторы и языки программирования -- это отдельная песня. А что касается GPL -- никто не заставляет отказываться от динамической линковки (и понимается (для справочки) динамическая линковка весьма по разному).
*вредоносного вклада
> Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?Присоединяюсь к вопросу. Сколько?
> А лицензия - дело второстепенное.
К сожалению нет.
Лицензия часто определяет будет жить проект или нет.
>> Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?
> Присоединяюсь к вопросу. Сколько?https://www.linuxfoundation.org/membership/members/
>> А лицензия - дело второстепенное.
> К сожалению нет.
> Лицензия часто определяет будет жить проект или нет.Если программа работает отлично, но проприетарная, то соответствующий проект могут выкупить вместе с разработчиками. А если она дерьмо, то тут никакая лицензия не поможет.
> Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?На удивление, довольно много. Загрепай по гиту, умник. Майкрософт один раз вообще в топ вошел. С поддержкой своего гиперви в линуксе, разумеется. В *бсд они врядли с этим пойдут - на линуксе 2/3 их azure видите ли, а на bsd у них какой % кастомеров?
> На удивление, довольно много. Загрепай по гиту, умник. Майкрософт один раз вообще
> в топ вошел. С поддержкой своего гиперви в линуксе, разумеется. В
> *бсд они врядли с этим пойдут - на линуксе 2/3 их azure видите ли, а на bsd у них какой % кастомеров?Ох уж эти сказочники ...
https://www.opennet.me/opennews/art.shtml?num=44570
> Компания Microsoft подготовила модифицированную версию FreeBSD для Azure
> 09.06.2016 09:04
> Сообщается, что большая часть подготовленных Microsoft изменений, нацеленных на увеличение производительности ввода/вывода и сетевой подсистемы, уже вошли в состав FreeBSD 10.3.https://www.opennet.me/opennews/art.shtml?num=34538
> Компания Microsoft открыла код для поддержки платформы виртуализации Hyper-V во FreeBSD
> 09.08.2012 23:43
> Компания Microsoft объявила о публикации на GitHub набора патчей для обеспечения полноценной поддержки запуска гостевых окружений с ОС FreeBSD
>В настоящее время ведётся работа по интеграции опубликованных патчей в основное дерево исходных текстов FreeBSD..
ну и зачем сие надо?
чтобы хранить порнуху более эффективно!
Дядь, это единственная рабочая COW FS с кучей функционала и которой не страшно доверить свои данные на всей планете (не считая APFS, которая закрыта).
Btrfs хранит данные миллиардов хомячков фэйсбука, вроде живые.
> Btrfs хранит данные миллиардов хомячков фэйсбука, вроде живые.…потому что могут нанять себе автора btrfs, а ленты далеко всё равно никто не листает.
> Дядь, это единственная рабочая COW FS с кучей функционала и которой не
> страшно доверить свои данные на всей планете (не считая APFS, которая
> закрыта).Чо? Т.е. я правильно понимаю, что RAID, софт-зеркалирование -- не надо, а NTFS допускает потери данных каждый день на предприятиях?))
Ну и ладненько. Пока на моей фре это не прилетело ещё.
держите в курсе ;)
Как форснуть дедупликацию на уже наполненном сторадже? И можно ли при этом сохранить избыточность (например есть 10 одинаковых файлов, нужно оставить не более двух копий)
Так если надо не более двух копий, делай zfs pool типа зеркало, вот и будет две копии всего. Или надо чего-то по одному, чего два? Тогда можно сделать зеркало на части диска и монтировать отдельно.
Дисочко уже нарезано, поэтому вариант "монтировать отдельно" не вариант, нужно чуть уменьшить занимаемое место на давно существующей хранилке, но при этом прихранить некоторую избыточность
Форсить только вручную. Сначала включить требуемые опции - дедупликацию/сжатие. Но это действует только на вновь записанные данные. Затем тупо гонять данные с места на место. Скопировал файло из одной директории в другую, переименовал директория обратно и вуаля - данные сжаты и в хеш дедупликации попали. Повторять порциями пока все файло не будет скопировано хотя бы один раз.
>> Но это действует только на вновь записанные данныеВот это как раз вгоянет в печаль на более-менее значимых объёмах
Теоретически, можно написать скрипт, который перемещает файлы в /tmp (например) и обратно в zfs...
> Теоретически, можно написать скрипт, который перемещает файлы в /tmp (например) и обратно
> в zfs...Теоретически, можно. Но практически это будет означать: ZFS не является ФС для всех.
Дедупликация на то и дедупликация что хранится одна копия, которая защищена избыточностью пула (raidzX) или копиями (zfs set copies=2).
>> хранится одна копиянемного не сходится с
>> или копиями (zfs set copies=2)Дедупликация - метод уменьшения избыточности. Метод сэкономить места на одинаковых данных. А сколько реальных копий должно оставаться - дело каждого
сходится. У тебя первоначальных копий могло быть 10. Всё это, условно, "сворачивается" в один экземпляр, который потом другими компонентами ФС дублируется уже для сохранности. Условно: было 10 - стало 2.
Так не или, а И.Физическая избыточность задается на уровне пула zpool количеством доп. устройств zmirror или raidz
А copies - это логическая избыточность на уровне dataset, задается командой ZFS (, а не zpool).
Т.е. ничто не мешает одновременно иметь например физически три зеркала zmirror на уровне zpool и поверх них две логических копии на уровне zfs copies=2 pool/dataset.И будет вам количество копий 3*2=6 ! Причем одновременно с дедупликацией хоть сотен бэкапов, например DB2 dedup.
Кроме "дедубликации" в ZFS есть еще и "дублирование"
для двух копий видимо делай 2 снапшота, с нужной тебе частотой
Эта штука имеет смысл для домашнего десктопа? Например, повысить производительность HDD и/или увеличить время работы ноутбука от батареи?
Да.
Что "Да"?
Какой выигрыш она даст на стандартном десктопном сценарии на WDC WD1003FBYX-01Y7B1?
значительный
Раз в 10 медленнее чем ext4 https://www.phoronix.com/scan.php?page=article&item=ubuntu19...
1. Компрессия на исходниках
2. Дедупликация если вы маньяк
3. Можете увеличить пространство за счет любого подключенного диска.
4. Если не додумались до бэкапа, то потеряете все данные по взмаху палочкой феи (из электросетей).
Ну, самое главное её сво
Ну, самое главное её свойство это защита от тихой порчи данных.
А побочное - очень годный софтварный рейд.
Так что можете например зеркало сделать, или RAID-Z
А если избыточность не интересна то сможет точно обнаружить повреждение данных и сказать какие именно данные повреждены.Другая удобная вещь это снимки. Для десктопа очень даже полезно. И бекапы делать очень просто.
Третья удобная вещь - сжатие на лету. Для уже сжатых файлов и прочего видео штрафа почти нет. Зато разнообразные сорцы и прочее сжимает очень круто попутно сильно ускоряя чтение и запись.
Нет.
Скорее наоборот. Я бы для домашнего пользователя ext4 посоветовал. Но если хочется ZFS - то конечно можно. Будет не на много медленнее, но уйдёт много ОЗУ на ARC. А ещё - бойтесь ООМ-ов в юзерспейсе, сюрпризы приносящих. Нам обещали эту проблему обойти в этом-следующем году, хоть это и не критично.
ЗФС можно оттюнить на низкое потребление.
По крайней мере раньше можно было.
обойти это очень просто, проставить параметры размера арка в конфиге
Да, добавляет емкость батареи +7000мАч, увеличивает скорость вращения шпинделя в ХДД на 43%
если только у вас в десктопе дисков больше 3х и + место в M2 для ARC
Да. Она повысит надёжность хранения данных и даст возможность восстановления в случае неудачных действий пользователя, например, при обновлениях.
> Да. Она [...] даст возможность восстановления в случае неудачных действий пользователя, например, при обновлениях.Ну, нет, если Вы про снапшоты, то это лишь ещё один удобный способ делать бекапы. Ручные. Если пользователь их не делает, снапшоты ему ничем не помогут. А если делает, то возможность восстановления у него уже есть.
Про надёжность, кстати, тоже спорное утверждение, случаи бывают разные.
А вот гибкость управления разделами файовой системы и перераспределения квот - это учень удобная тема.
> Ну, нет, если Вы про снапшоты, то это лишь ещё один удобный
> способ делать бекапы.Ну какие же это бекапы, если они не спасают ни от кражи, ни от пожара, ни от пользователя, который решает покупать ST3000DM001-ы пачками в один RAID из соображений мифической производительности? А в остальном, конечно, инструмент удобный.
>> Ну, нет, если Вы про снапшоты, то это лишь ещё один удобный
>> способ делать бекапы.
> Ну какие же это бекапы, если они не спасают ни от кражи,Да, довольно странно считать snapshot исключительно аналогом бэкапа.
Бэкапы (снимки) можно инкрементально по сети пересылать в другой zfs
> Бэкапы (снимки) можно инкрементально по сети пересылать в другой zfsВот тот другой zfs и будет бэкапом. А снимки на основной системе так и останутся просто снимками.
В первую очередь на случай если юзверь самостоятельно что-то запорет и надо оперативно вернуться.
А что, вас часто грабят и поджигают?
> А что, вас часто грабят и поджигают?«Если у вас паранойя, это ещё не значит, что за вами не следят.»
Да нормальные это бекапы. Если пользователь считает достаточным бекапить свои важные данные в отдельную папочку на том же диске, это его решение и снапшоты ZFS будут ничем не хуже, скажем, рсинка. Если же не считает, то кто ему мешает хранить снапшоты на удалённой машине?
Одним из способов применения снапшотов являются boot environments. Впрочем, я не уверен, что последние доступны в Linux. А есть ещё checkpoints.
> Эта штука имеет смысл для домашнего десктопа? Например, повысить производительность HDD
> и/или увеличить время работы ноутбука от батареи?Защититься от злого шифровальщика.
Почему-то забывают упомянуть про прозрачное криптование.
Спокойней на душе в случае, например, кражи. Если есть конечно бэкап, который по всем правилам должен быть физически где-то в другом/других местах, и по той же причине тоже криптованным.
ZFS прекрасно работает поверх люксованных дисков, родное шифрование ZFS вроде бы не шифрует даже метаданные, оно надо такое?
а чего для домашнего применения не использовать btrfs ?
Спасибо, кэп, это уже даже до федоры дошло.
Теоретики лицензий, раскажите, что мешает им выпустить своё поделие под GPL?
> Теоретики лицензий, раскажите, что мешает им выпустить своё поделие под GPL?Мешает упёртость Oracle, который не спешит перелицензировать свой код ZFS, на котором основан OpenZFS. Без изменения лицензии на код Oracle, разработчики OpenZFS могут изменить лицензию лишь на свои изменения, что никуда не денет проблему с поставкой основного кода под CDDL.
Мешают те же причины, по которым и в ядре все гплизируется
GPL -это Свобода. А ты враг Свободы!
Идея состояла в том, чтобы на волне успеха Linux попытаться попробовать выпустить Solaris как свободный продукт и поднять его популярность. При этом было понятно, что вместо поддержки двух ОС, корпорации бы просто перетащили самые вкусные куски кода из Solaris в Linux, поэтому надо было позаботиться о том, чтобы существовавшие тогда преимущества Solaris, такие как Dtrace, ZFS не утекли в Linux.Так появилась CDDL - то же самое, что и GPL, копилефтная свободная лицензия. Код под CDDL не совместим с GPL - ведь обе лицензии требуют, чтобы производный код сохранял лицензию, а значит, GPL код не может быть связан с CDDL и обратно.
Ну и поскольку код ZFS on Linux базируется на коде ZFS из Solaris, он обязан лицензироваться под CDDL.
P.S. И передавайте привет идиоту-анонимусу, который пишет, что CDDL свободнее GPL, хе-хе.
>ведь обе лицензии требуют, чтобы производный код сохранял лицензиюCDDL позволяет использовать другие лицензии в составе проекта и даже распространять проект CDDL под другой лицензией. Так что, упёртый тут только GPL.
> CDDL позволяет использовать другие лицензии в составе проекта и даже распространять проект
> CDDL под другой лицензией. Так что, упёртый тут только GPL.Нет. CDDL — это аналог LGPL, он позволяет распространять код в составе другого проекта, но не позволяет проект под CDDL под другой лицензией. Иначе он был бы совместим с GPL.
>CDDL — это аналог LGPLLGPL совместим с GPL. Если бы CDDL был бы аналогом, была бы совместимость тоже.
>>CDDL — это аналог LGPL
> LGPL совместим с GPL. Если бы CDDL был бы аналогом, была бы
> совместимость тоже.Именно. Его намеренно сделали несовместимым.
Интересно, когда с ним выйдет какой-нибудь армбиан свежий, со следующим LTS-ядром, чтобы на 4-ую малинку вкорячить и получить наконец-то нормальный NAS
Нормальный нас на малинке это что-то новенькое.
Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4 в зеркало - это тоже нифига не нормальные насы. А тут хоть какой-то шанс.
FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм, проц норм, ОЗУ хватает - почему бы и не быть ему нормальным
+XigmaNAS
> Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4
> в зеркало - это тоже нифига не нормальные насы. А тут
> хоть какой-то шанс.
> FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм,
> проц норм, ОЗУ хватает - почему бы и не быть ему
> нормальнымНу если нужна файлопомойка с низкой производительностью и парой терабайтных блинов, может малина и потянет (сколько у ней оперативы можно?)
Пвсеннс фаервол.
> Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4
> в зеркало - это тоже нифига не нормальные насы. А тут
> хоть какой-то шанс.
> FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм,
> проц норм, ОЗУ хватает - почему бы и не быть ему
> нормальнымКоробки лучше отбросить. Собери сам, будет гибче и дешевле. Для дома уж точно.
Нормальный - от 12-16 гигабайт оперативки и проц уж не ниже фенона.
> Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4
> в зеркало - это тоже нифига не нормальные насы. А тут
> хоть какой-то шанс.
> FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм,
> проц норм, ОЗУ хватает - почему бы и не быть ему
> нормальнымФринас интерпрайзное и полуинтерпрайзое решения. Рекомендуемые требования - от 16 гигабайт рамы. Естественно, он будет работать на гораздо более слабых конфигурациях, но "перформанс", да и просто комфортную работу с ним не получишь.
Насфофри попробуй. Или опенмедиавульту.
А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить тяжелые фичи (типа дедупликации), оставив сжатие...
В общем случае специальная настройка (на FreeBSD) не требуется.
как показала практика, для общих случаев, где не требуется спец. настроек и специальных фич - нужность zfs стремится к нулю и можно обойтись обычной юфс.
У UFS нельзя одновременно задействовать снапшоты и Soft Updates, а это частенько бывает нужно.
Дедупликация по умолчанию отключена, для самого ARC рекомендуется выделять объём 1 Гб и выше. Если нет постоянных или больших потоков данных, используется типа а-ля десктоп, то скорее всего и со ~200Мб под ARC будет работать так же.
> Дедупликация по умолчанию отключена, для самого ARC рекомендуется выделять объём 1 Гб
> и выше.1 Гб на каждый 1 ТБ хранилища, насколько помню. Искать ссылку лень, кому важно, тот сам эти цифры знает.
Пожалуйста, не говорите ерунды, если не в теме.1Гб достаточно если без дедупликации даже на exabyte хранилище.
Почитайте не "ХауТо" блоги, а ответы на эту тему реальных разработчиков ZFS:
https://www.reddit.com/r/DataHoarder/comments/5u3385/linus_t.../
https://www.reddit.com/r/DataHoarder/comments/5u3385/linus_t.../
Если без давайте без если и без. Т.е. По факту ей надо полтерабайта памяти и больше на типичное использование а ля подкроватный сервер. Как с этим у btrfs сейчас?
> Если без давайте без если и без.В ZFS по умолчанию выключена дедуплекация, о каких "без" не "без" разговор?
>Т.е. По факту ей надо полтерабайта памяти и больше на типичное использование а ля подкроватный сервер.
С английским проблема посмотреть ссылки приведеные выше?
1Гб памяти достаточно для любого обьема
> Как с этим у btrfs сейчас?FYI: Поддержка btrfs была остановлена одним из главных спонсоров линукса - т.е. красношляпой
>по умолчанию выключенаКакой смысл использовать дефолт?
>1Гб памяти достаточно для любого обьема
Зачем же такая очевидная ложь? Не любого, далеко не всегда эффективно, и без дедупликации естественно.
>FYI: Поддержка btrfs была остановлена одним из главных спонсоров линукса - т.е. красношляпой
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-3...
>Зачем же такая очевидная ложь? Не любого, далеко не всегда эффективно, и без дедупликации естественно.А кто говорил про эффективность? Естественно, чем больше памяти, тем лучше, но если как было сказанно - подкроватный вариант, то работать будет. 100% (если руки конечно из правильного места)
И вы не бложики популярные читайте, - а оригиналы:
https://access.redhat.com/discussions/3138231
Наиболее заметные улучшения в Fedora 33:Все варианты дистрибутива для рабочего стола (Fedora Workstation, Fedora KDE и т.п.) переведены на использование по умолчанию файловой системы Btrf
6TB пулы работают просто прекрасно на Core2Duo всего с двумия гигами рамы под Devuan.
Добавление SSD кэширования еще более улучшает все это.
> Как с этим у btrfs сейчас?Живет на роутере с 64 мегами. Нормально?
> Пожалуйста, не говорите ерунды, если не в теме.
> 1Гб достаточно если без дедупликации даже на exabyte хранилище.Дословно "не должно быть массы проблем" ("would not have much trouble"). В общем, нет противоречий со средней температурой по больнице.
> Почитайте не "ХауТо" блоги, а ответы на эту тему реальных разработчиков ZFS:
Я не читал блоги до Вашей ссылки на reddit, только issues zfsonlinux.
> 1 Гб на каждый 1 ТБ хранилища, насколько помнюА вы не помните, вы головой подумайте. Есть горячие данные, есть холодные. Для горячих нужен ARC, а сколько холодных, а тем более места в хранилище, ему глубочайше насрaть.
Если хранилище используется как лента, ARC вообще не нужен. Если на хранилище идёт значительная нагрузка в виде равномерно наспределённого случайного доступа, ARC имеет смысл делать либо размером в хранилище, либо вообще не делать потому что он иначе никак не поможет. Если доступ распределён неравномерно, то оптимальный размер arc может лежать где угодно в диапазоне от 0 до размера хранилища и зависит от множества факторов.
Сделай одолжение, найди свою ссылку, узнай её автора и напиши ему что он некомпетентный графоман-вредитель.
А как он дедуплицировать будет?
> А как он дедуплицировать будет?А зачем ??? У вас правда столько много одинаковых котиков раскиданных по всему диску чтоб экономить через дедупликацию?
Ты не поверишь сколько одинаковых котиков. Я прошёлся hardlink и освободил примерно так треть пространства, но метаданные и атрибуты были утеряны конечно и в идеале этого стоит избежать. И это ведь только абсолютно идентичные данные, а сколько их частично совпадающих? Да 2/3 оставшегося наверно.
Дедупликация бэкапов DB2 с опцией DB2 dedup позволяет добиться снижения занимаего физического пространства в количество раз, равное примерно количеству бэкапов.Например, если у вас 1000 бэкапов, то они займут примерно в 1000 раз меньше места, ну может в 300-500 раз с поправкой на дельты и т.п.
Только потом для операций на удаление, например, снэпшотом даже при количестве рамы в 8 гиг будет уходить очень много времени. Поэтому чтобы почистить такой пул с бэкапами от старых бэкапов проще просто его дропнуть и создать новый, иначе будете его чистить неделями, если не месяцами.При это запись и чтение работает вполне приемлемо по скорости, до тех пор пока пул не переполнится. Т.е. дедупнутые пулы OpenZFS - это как бы такие ленточки, на которые можно только писать и с которых можно читать, но не удалять. А если нужно удалить, то проще (быстрее в 1000 раз) "размагнитить" всю ленточку командой zpool destroy.
Я не спорю, что задачи разные бывают, но вы прочитайте пожалуйста оригинальный вопрос еще раз:
>"А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить тяжелые фичи (типа дедупликации), оставив сжатие..."Вы правда думаете что в этом случае нужна дедупликация ?
> Например, если у вас 1000 бэкапов, то они займут примерно в 1000
> раз меньше места, ну может в 300-500 раз с поправкой на
> дельты и т.п.ZFS поддерживает инкрементальные бекапы снапшотов.
> Например, если у вас 1000 бэкапов, то они займут примерно в 1000 раз меньше места,...но когда сыпанется под общим для них всех набором блоков, мы скажем "во бл$!"
Неправильно ты бэкапы делаешь, дядя. 1000 кратная избыточность на одном массиве это не правильно.
>> 1 Гб на каждый 1 ТБ хранилища, насколько помню
> А вы не помните, вы головой подумайте.Над чем? Есть вопрос пользователя. Похоже, его запугало мнение экспертов, что ZFS съедает всю память и даже косточки не выплёвывает.
> Есть горячие данные, есть холодные.
> Для горячих нужен ARC, а сколько холодных, а тем более места
> в хранилище, ему глубочайше насрaть.Вот только часть:
* The hash table is big enough to fill all of physical memory
* with an average block size of zfs_arc_average_blocksize (default 8K).
* By default, the table will take up
* totalmem * sizeof(void*) / 8K (1MB per GB with 8-byte pointers).https://github.com/openzfs/zfs/blob/zfs-2.0-release/module/z...
> Если хранилище используется как лента, ARC вообще не нужен. Если на хранилище
> идёт значительная нагрузка в виде равномерно наспределённого случайного доступа, ARC имеет
> смысл делать либо размером в хранилище, либо вообще не делать потому
> что он иначе никак не поможет. Если доступ распределён неравномерно, то
> оптимальный размер arc может лежать где угодно в диапазоне от 0
> до размера хранилища и зависит от множества факторов.* This is the easy case; all clean data contained by the mru and mfu
* lists is evictable. Evicting all clean data can only drop arc_size
* to the amount of dirty data, which is greater than arc_c_min.> Сделай одолжение, найди свою ссылку, узнай её автора и напиши ему что
> он некомпетентный графоман-вредитель.Простите, но с такой целью я только вот что могу найти, а с авторами сами разбирайтесь:
В настоящее время минимальный объем памяти, рекомендуемый для установки
системы Solaris, составляет 768 МБ. Однако для обеспечения высокой
производительности ZFS рекомендуется по крайней мере 1 ГБ памяти или более.
Нормально работает, на 4гб как минимум. Размер ARC настраивается через modprobe, вот образец на 512 мб мин, 2 гб макс. Кэш он и есть кэш. Много памяти надо для дедупликации только.options zfs zfs_arc_min=536870912
options zfs zfs_arc_max=2147483648Осталось понять что именно от зфс вам хочется и почему, ибо она в целом медленней (но вполне терпимо).
> А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить
> тяжелые фичи (типа дедупликации), оставив сжатие...На четырех он и без настроек нормально работал на ноуте. Правда там фрибсд была, как в Линукс не знаю.
Там ничего не нужно настраивать. Дедупликация по умолчанию выклчючена, ARC при memory pressure сам сжимается. На 512MB VPS'ке, например, он замечательно живёт с кучей сервисов без каких бы то ни было настроек.Миф о том что для ZFS нужна куча памяти родился в давние времена когда ещё были достаточно распространены 32битные платформы, и на FreeBSD где ZFS активно начали пробовать действительно была проблема когда i386 система паниковала из-за нехватки адресного пространства (не физической памяти!). Больше ничего объективного намекающего на необоснованное потребление памяти нет. Но есть куча необразованных обезьян, которые еле-еле освоили что в эффективно работающей системе Free памяти быть не должно, как опа! появляется новая сущность arc, которая вдруг "съедает" всю память. Сразу срыв шаблона, паника и истерика. Не уподобляйтесь таким.
> А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить
> тяжелые фичи (типа дедупликации), оставив сжатие...Можно.
ZFS тюнется на малые объемы ОЗУ очень неплохо.>типа дедупликации
Она никогда не должна быть включена ни где. И не включена.
Включать если у вас есть много героина и молоток.
> ZFS тюнется на малые объемы ОЗУ очень неплохоКак именно тюнется?
>> ZFS тюнется на малые объемы ОЗУ очень неплохо
> Как именно тюнется?
> Она никогда не должна быть включена ни где. И не включена.Слишком смелое утверждение.
У меня дедуплицикация фс, занимающей 6Тб на диске, потребляет меньше 4 гигабайт памяти:
dedup: DDT entries 22107989, size 511B on disk, 165B in core
Коэффициент дедупликации 4:1.
Каков юзкейс, что храните, каковы нагрузки?
Единственный известный мне случай оправданной детупликации это куча виндовз виртуалок.
Бэкапы виртуалок вмвари, хранятся 10 последних дней
> Бэкапы виртуалок вмвари, хранятся 10 последних днейДа, один из немногих случаев когда дедупликая может быть полезной...
Кстати, с сжатием просто сравнивали?
Чем оно лучше btrfs?
В общем-то, всем.
Ну кроме снапшотов.
А что не так со снэпшотами в ZFS? Работают же.
Снапшоты в btrfs удобнее (линейная по времени цепочка неизменяемых снапшотов в zfs и дерево в btrfs)
Особенно 128-битностью
Единственный минус - отсутствие любого подобия shrinking (by design?)
Ну и что тебе даёт 128-битность? +100500 к чсв?
ZFS(big) -> backup -> ZFS(small)
Глючная штука на которую не действуют конфиги а выдаваемые ошибки не имеют обьяснений.
А есть информация, как произойдет переезд с текущей реализации ZFS во Freebsd 11/12 на OpenZFS в будущих релизах при обновлении рабочей системы?Что бэкапы наше все - это понятно и тривиально...
Я использую в 12.2, функционал и опции перенесены частично. Смотрел в 13-м - там уже все на месте, как на линуксе. Права всё те же ACL NFS4
Официальный переезд запланирован на 13.0-RELEASE. Сейчас же её можно поставить из портов, включая модуль ядра.
Это я знаю...
Я имел в виду - в ходе freebsd-update -r 13.0-RELEASE upgrade существующие zfs-пулы/ФС/данные не накроются медным тазом?
Да ну с чего бы?
Там опасения, скорее связаны с тем, что во FreeBSD приедут (прежние?) проблемы ZFS на Linux.
А где про тестирование, про надежность ФС??
> "Стабильность кодовой базы OpenZFS оценивается как сопоставимая с другими ФС для Linux."
Почему у них своего гита нет?
https://github.com/openzfs/zfs
Это гит мелкомягких.
buzzword :)
Ждём в Proxmox 6.4!
Поставлю любую ФС если она не будет дёргать диск и моргать этой долбаной лампочкой. Хотя насколько я понял, все ядра, начиная с 4-й версии имеют диск вдоль и поперёк, даже ext2, но ведь удавалось же обеспечить нулевое обращение к диску при простое например на том же Debian 8 с ядром 3.16 и ниже, вот прям ноль, хоть десять лет работает. Линус, ты делаешь что-то не то.
Та как бы диск не файловая система дёргает.
Дело не в ядре. Специально проверял, собирал одно и то же ядро в Fedora 25 и 26. В 26 и выше лампочка HDD вспыхивает каждые 2 сек. В 25 тишина, пока что-нибудь не запишешь. Судя по всему это какой-то сервис, не удивлюсь, если из комплекта systemd.
> Судя по всему это какой-то сервис, не удивлюсь, если из комплекта systemd.Скорее всего так и есть, если например logrotate и подобное легко выпиливалось, то journald намертво вшито.
Если бы это было так, диски бы не парковались каждые 5 минут.
> Если бы это было так, диски бы не парковались каждые 5 минут.Вот причём здесь парковка? Тем более её легко отключить
в
/etc/hdparm.conf
смените
#apm_battery = 127
на
apm_battery = 255По крайней мере раньше было так.
Нуу это сильно раньше, на современных дисках парковка не отключается. Вроде даже как совсем. Если бы ядро дёргало диски, они бы не парковались, но они паркуются и не просыпаются пока не понадобятся какие-нибудь файлы. Можно в iotop -oa наверно посмотреть кто дёргает, но если это какой-нибудь крон, то не отобразится.
Что это за современные диски такие, вроде ж техпроцесс на HDD не меняется десятилетиями, тут надо копать в daemon/service и с корнем такое выпиливать.
Вообще-то каждые пару лет всё меняется очень значительно. Не выпилишь ты парковку, она в прошивке зашита. Они видимо решили что достаточно обкатали на прошлых поколениях и теперь можно принудительно парковать. В принципе это не сотни тысяч парковок в месяц, но штук 10 за день легко набирается и доступ к паркованным дискам чересчур уж медленный. Если хочешь убить диск более эффективно включи остановку шпинделя.
> Вообще-то каждые пару лет всё меняется очень значительно. Не выпилишь ты парковку,
> она в прошивке зашита. Они видимо решили что достаточно обкатали на
> прошлых поколениях и теперь можно принудительно парковать. В принципе это не
> сотни тысяч парковок в месяц, но штук 10 за день легко
> набирается и доступ к паркованным дискам чересчур уж медленный. Если хочешь
> убить диск более эффективно включи остановку шпинделя.А всё таки это из-за ядра, так как я ставил и Devuan, и MXLinux/Antix, там нет systemd, а диск дёргало будь здоров, скорее всего какая-то подсистема для ускорения доступа до ФС.
Современные диски очень разные.
И на большинстве парковкой можно управлять из вне.
на ext4 ставил commit=900, и годами жил на корне который на флешке.
> на ext4 ставил commit=900, и годами жил на корне который на флешке.Спасибо, добавил к noatime,nodiratime,nobarrier, а вот lazytime под вопросом.
А кто-нибудь знает где можно проверить ключ, которым подписан .tar.gz ? Новых бинарных сборок 2.0.0 под дистрибутивы пока нет, а старые сборки подписаны gpg ключами ментейнеров, которые тоже не понятно где проверять...
ZFS это хорошо
Впилили бы zstd компрессию в ext4, и не надо больше ничего
Лучше webp.
Она есть, называется VDO Layer
Мало, очень мало прлслоек. Нужно больше!
Мысль вслух - а может попробовать компрессию на F2FS...
Оно уже научилось дефрагментации?
> Оно уже научилось дефрагментации?Каков ваш юзкейс вызывающий повышенную фрагментацию ZFS?
Как быстро перфоманс деградирует?
Любой юзкейс где файлы не аллоцируются сразу а дописываются в процессе вызывает сильную фрагментацию. Например, типично самое фрагментированное, это профили браузера (для линукса).
Профиль браузера у вас вызывает фрагментацию ZFS?
Или вы не знаете, а только предполагаете?
ИМХО, нужно проверять.ZFS кстати COW система, на всякий случай отмечу.
Ext4 он определённо точно фрагментирует очень сильно, а ведь ext4 как известно тоже "не фрагментируется", только даже e4defrag плачет кровавыми слезами от кэшей браузера. Однако, свободное пространство адово фрагментирует, но у неё хотя бы какой-то онлайн дефрагментатор есть.
> Ext4 он определённо точно фрагментирует очень сильно, а ведь ext4 как известно
> тоже "не фрагментируется", только даже e4defrag плачет кровавыми слезами от кэшей
> браузера. Однако, свободное пространство адово фрагментирует, но у неё хотя бы
> какой-то онлайн дефрагментатор есть.Надо тестировать. ZFS - совсем другая система. Я слышал о проблеме фрагментации на ней, но точно не на профилях браузера.
И обычно рекомендуют оставлять больше свободного места или добавить дисков в пул для повышения IO.В любом случае, вначале тестирование - потом решение. Скорее всего, ненужно ничего для кешей браузера дефрагментировать никогда вообще.
Как варианты, отключить кеш на диске, или разместить кеш на ССД.
Не только профили браузера, это просто пример постоянно пишущихся файлов. Ещё жесть была на cow образах виртуалок. И раньше ещё сталкивался с фрагментацией на торрентах, когда программа не аллоцировала сразу весь файл целиком. Дефрагментатора на линуксах очень не хватает, файлы читающиеся подряд чаще всего будут разнесены по всем блинам ровным слоем даже если они не фрагментированы, это тоже значительно снижает производительность (поэтому доступ к куче мелких файлов такой медленный). Ну и консолидировать свободное пространство наверное хотелось бы. Не подходит линукс для высокопроизводительных рабочих станций, ничего не поделать.
>И раньше ещё сталкивался с фрагментацией на торрентах, когда программа не аллоцировала сразу весь файл целикомНужно аллоцировать, иначе торренты жесткий диск вешают.
>Не подходит линукс для высокопроизводительных рабочих станций
Высокопроизводительные рабочие станции используют ССД, как и большинство домашних ПК. А чтобы словить проблему с фрагментацией на HDD нужно очень хорошо постараться, так как современные файловые системы это дело давно научились оптимизировать.
>Дефрагментатора на линуксах очень не хватает
Вы всегда можете провести офлайн дефрагментацию раз в 5 лет.
Если у вас это постоянная проблема то нужно устранять причины её возникновения.
ССД не напасёшся, они конечно идут под кэши, но это всё довольно ограничено в итоге. Плохо ФС это оптимизируют, очень плохо.>офлайн дефрагментацию раз в 5 лет
Ну да, если бы она ещё существовала. Есть эффективный метод переместить файлы с диска на диск, но это неделями нонстоп диски долбить же и их нельзя при этом использовать. Не вариант.
Что касается фрагментации свободного пространства, то за год использования на корне картина такая
Min. free extent: 4 KB
Max. free extent: 190888 KB
Avg. free extent: 424 KB
Num. free extent: 76118на разделе с данными
Min. free extent: 4 KB
Max. free extent: 2080640 KB
Avg. free extent: 1636 KB
Num. free extent: 258754Если файл попадёт в эти миллионы 4 килобайтных экстентов, ему поплохеет. А когда их будет больше одного, и они все размазаны? У ссд внутреннее представление вроде бы 20 мегабайт, не уверен, как это всё сказывается на их эффективности.
Особенно весело становится когда случайный доступ в несколько потоков, а файлы размазаны. Вот это да, так и убить диски не долго (если они раньше не отключатся от перегрева сами).
> Особенно весело становится когда случайный доступ в несколько потоков, а файлы размазаны.
> Вот это да, так и убить диски не долго (если они
> раньше не отключатся от перегрева сами).Никакая дефрагментация тут не поможет. Это ограничения жестких дисков как технологии. Решается сборкой рейд массивов и настройкой кеширования.
Диски читают в свой кэш относительно большими блоками (даже очень большими), а если файлы расположены рядом то ещё и значительная экономия на позиционировании. Т.е. в каталоге с кучей мелких файлов более выгодно будет разместить их рядышком, а не по всем пластинам.
> Диски читают в свой кэш относительно большими блоками (даже очень большими), а
> если файлы расположены рядом то ещё и значительная экономия на позиционировании.И как это поможет когда у вас
>случайный доступ в несколько потоков?
На позиционирование понадобится много меньше времени, если файлы сразу попадают в кэш (либо как минимум расположены рядом). Если же их придётся искать по всем пластинам, никакого толка не будет.
Доступ же случайный, откуда файлам в кеш попадать, и какая разница как близко они находятся если доступ случайный?
Наверное всё же не совсем случайный. Тут вычитал тысячу файлов за один заход, там 10 тысяч файлов. Кроме того, диски достаточно умные, чтобы оптимизировать доступ к рядом расположенным данным.
Нет, диски не обладают подобным интеллектом.
Или обладают, они определённо умнее среднего пользователя. Сегодняшние нжмд исключительно высокотехнологичны.
Вот и не додумывайте тогда за ШДД и файловые системы, им виднее.
Ну это уже откровенное хамство, да? Будем считать за слив и отсутствие адекватных аргументов.
Вам заняться нечем, кроме как меня троллить?
Вы единственный кто здесь хамит.Все ваши комментарии сводятся к попытке придумать причину для необходимости механизма онлайн дефрагментации, в виду ваших слабых познаний в теме попытке нелепой.
Как я должен на ваши вольные фантазии отвечать, по вашему?Давайте перефразирую, мне неинтересны ваши фантазии, и вам не стоит тратить на них время, подобные занятия ведут к шизофрении.
Ну это стадия отрицания, не иначе. Пример низкой квалификации, да? Поскольку любой, кто работал с сильно фрагментированными данными (и видел разницу между размазанными данными и локально сгруппированными), понимает, насколько это плохо для производительности и почему.
Пс. я, конечно, могу совершенно добросовестно заблуждаться, но я хотя бы проводил исследование, и что-то мне подсказывает, что я вполне корректен в полученных выводах. Если, конечно, не допустил ошибку при анализе, но в таком случае она была совершена многократно и оборудования для получения более достоверного результата у меня в наличии не было в любом случае.
Подтверждаю, ZFS жутко фрагментируется и тормозит от профиля Chrome, уже 4 раза приходилось делать send | receive для дефрагментации, после чего браузер перестает подолгу тормозить.И это в режиме sync=disabled, когда по сути все пишется первые несколько минут только в оперативку.
Т.е. получается, затраты по IOPs только на чтение.И дальше берем базу СУБД на zvol, через несколько лет она становится жутко фрагментированной, но это еще полбеды, потому что часть ее можно загнать в L2ARC на SSD.
Намного серьезнее проблем с фрагментацией свободного места, которое решается постепенным добавлением нового свободного места, после чего запись опять оживает.
Ну ни нада звиздеть про ненужность дефрагметации, это же дичайшая дичь тупая, почейтайте лучше, что пишут умные люди:
https://serverfault.com/questions/957317/zfs-heavy-write-amp...
https://github.com/openzfs/zfs/issues/4785
Ну если вы просто троль производителей СХД, то я вас еще могу понять, потому что после появления в ZFS онлайн дефрагментации вас ждет финансовый кирдык, что я приветствую как пострадавший (к счастью только потерей своего времени) от хоронилищ IBM в составе Blade Center S.
Во всех уважающих себя промышленных хранилищах есть online дефрагментация, и я больше скажу, когда такая дефрагментация появится в ZFS, а она однозначно появится, когда подсуетятся промышленные пользователи, так вот тогда, все эти дорогие промышленные хранилища начального и среднего уровня пойдут по писе, ну может останутся девяточные с дублированием матплат и т.п. и то с учетом существования кластерных FS типа CEPH это еще большой вапроз.
Сами-то свои ссылки читали?
И куда вас понесло, что там за промышленные хранилища и причем тут онлайн дефрагментация в ЗВС?
Здесь рыбы нет (директор стадиона).
>ССД не напасёшсяНа кеш браузера и логи?
>они конечно идут под кэши, но это всё довольно ограничено в итоге. Плохо ФС это оптимизируют, очень плохо.
ZFS очень хорошо это оптимизирует.
Попробуйте тестовый сетап сделать, 6 винчестеров, сцепляете по два в vdev и из них RAID-Z.
Рядом 2 ссд в зеркало и подключаете к пулу как хранилище метаданных.
По вкусу добавляете NVME ссд для L2-ARC и один в кач ЛОГ девайса.
Я сумку на плече ношу либо рюкзак, кейсами не пользуюсь. И про Перфоманса не знаю, среди знакомых людей с такой фамилией нет.
А почему вас это беспокоит? Я вот не вижу проблем с производительностью на ZFS c 73% фрагментацией. Кстати, вы точно правильно понимаете что этот показатель означает в ZFS?
DRAID еще не допилили.
Нормальная фс для больших объемов самое то.
> OpenZFS уже используется в основной ветке FreeBSD (HEAD)HEAD это не ветка!
Насколько я выяснил (на openzfs.org/wiki/Main_Page) OpenZFS использует git в качестве системы контроля версий.В git, HEAD - это указатель на текущую ветку.
Поэтому фраза имеет (точнее _фраза_не_имеет_смысла) следующий смысл -
"OpenZFS уже используется в основной ветке FreeBSD (любой ветке в которую сделан git checkout или git switch)"
FreeBSD вообще-то старше git и HEAD может использоваться как устоявшееся обозначение
https://www.freebsd.org/cgi/man.cgi?cvs
> HEAD refers to the most recent version available in the repositoryеще со времен живых мамонтов и компьютеров из натурального кремНЯ
т.е. фраза означает, что оно вот тут https://svnweb.freebsd.org/base/head/
> Добавлена поддержка алгоритма сжатия zstd (Zstandard), который демонстрирует в 3-5 раз более
> высокую скорость сжатия по сравнению с zlib/DeflateПрям в 3-5 раз более высокую скорость сжатия?... Т.е. эти ребята возможно:
1) научились читать данные с диска в 3..5 раз быстрее
2) открыли какой-то волшебный алгоритм?))
Подтверждаю, ZFS жутко фрагментируется и тормозит от профиля Chrome, уже 4 раза приходилось делать send | receive для дефрагментации, после чего браузер перестает подолгу тормозить.И это в режиме sync=disabled, когда по сути все пишется первые несколько минут только в оперативку.
Т.е. получается, затраты по IOPs только на чтение.И дальше берем базу СУБД на zvol, через несколько лет она становится жутко фрагментированной, но это еще полбеды, потому что часть ее можно загнать в L2ARC на SSD.
Намного серьезнее проблем с фрагментацией свободного места, которое решается постепенным добавлением нового свободного места, после чего запись опять оживает.
Ну ни нада звиздеть про ненужность дефрагметации, это же дичайшая дичь тупая, почейтайте лучше, что пишут умные люди:
https://serverfault.com/questions/957317/zfs-heavy-write-amp...
https://github.com/openzfs/zfs/issues/4785
Ну если вы просто троль производителей СХД, то я вас еще могу понять, потому что после появления в ZFS онлайн дефрагментации вас ждет финансовый кирдык, что я приветствую как пострадавший (к счастью только потерей своего времени) от хоронилищ IBM в составе Blade Center S.
Во всех уважающих себя промышленных хранилищах есть online дефрагментация, и я больше скажу, когда такая дефрагментация появится в ZFS, а она однозначно появится, когда подсуетятся промышленные пользователи, так вот тогда, все эти дорогие промышленные хранилища начального и среднего уровня пойдут по писе, ну может останутся девяточные с дублированием матплат и т.п. и то с учетом существования кластерных FS типа CEPH это еще большой вапроз.
Для уменьшения фрагментации можно подтюнить recordsize https://jrs-s.net/2019/04/03/on-zfs-recordsize/
Интересно, какой нужен volblocksize для профиля Chromium в ext4 поверх zvol блока?Наверно, нужно сначала выбрать оптимальный размер блока для ext4 и потом такой же для zvol?
А как выбрать оптимальный?