Comments 36
Поэтому Оракл и держит патент? И, кстати, самих оракловцев кто-то спрашивал по поводу лицензирования, или это мнение Линуса, давно и последовательно нелюбящего zfs?
А то немного непонятно и больше похоже на «В-первых, я не брал твоих яблок, а во-вторых, всё равно они были кислые и невкусные»
В любом случае, интересно, запросы в оракл кто-то писал или просто ждут
PS немного работал с этими оракловыми zfs-хранилищами: особых проблем нет, кроме резкого падения скорости, когда место занято более чем на ~80% и вместо создания новых страйпов начинают дописывать в старые. Правда, такое поведение описано в мануалах, но ктож их читает?..
а) CDDL была специально написана с целью GPL-несовместимости, чтобы исходники Solaris и ZFS в частности не могли быть включены в Linux
б) ZFS защищен 56 патентами. И надо сказать, что тогдашний Sun был гораздо дружественне к разработчикам из других компаний, чем сегодняшний Oracle.
Учитывая вышесказанное, мало кто сомневается, что если ZFS включат в ядро, то довольно быстро придет Oracle и начнет судиться.
Это не про ZFS, так как у него просто нет аналогов. Самое близкое — BTRFS, но и там до сих пор нормальный Parity RAID не реализовали, да и RedHat/IBM уже забил на его развитие.
Использую ZFS дома на Linux уже под 10 лет (с первых его версий, работавших через FUSE) для файлопомойки — отличная штука. Многие достаточно полезные фичи, вроде дедупликации, правда практически невозможно использовать даже если у тебя 256Gb RAM (проверял, производительность падает катастрофически).
Но в остальном это единственная ФС дающая гарантии целостности данных и их восстановления в случае повреждений.
Это не про ZFS, так как у него просто нет аналогов
И что же там такое уникальное и нужное есть, чего нет у других? Я вижу необоснованный хайп вокруг zfs последние лет 5 и не могу понять чем он вызван
Что важно для меня (по мере уменьшения значимости):
1) Чексуммы данных и метаданных с прозрачной проверкой и лечением битых блоков используя встроенный RAID-Z. Это спасает от битых HBA-контроллеров и даже иногда памяти. Плюс, когда у тебя пулы на десятки-сотни терабайт — битовые ошибки становятся нормой, а не исключением. У современных дисков по даташитам ошибка 1 бит на 10^15, что уже почти сравнимо с объемом одного диска.
В BTRFS это частично есть, хотя алгоритм для контрольных сумм там слабенький (CRC32) как по мне. В ZFS их много и можно выбирать. Ну и RAID5/6 там еще не помечен как продакшен-реди.
2) Интегрированные снапшоты и клоны — использую для удобных бекапов через простой скриптик на 30 строк. В BTRFS это тоже есть вроде бы.
3) Компрессия немного помогает, особенно учитывая что с LZ4 она почти бесплатная. В BTRFS есть.
4) Возможность приделать SSD в качестве L2ARC или SLOG дома особенно не нужна, но если крутишь там всякие ВМ — то помогает сгладить скачки IOPS.
В BTRFS нет, но можно решить уровнем ниже через всякие flashcache и подобные.
5) Инкрементальные бекапы через zfs send/receive достаточно удобны — можно diff между снапшотами передать через любой канал умеющий читать из stdin.
6) Шифрование. Я пока шифрую диски под ZFS пулом через dmcrypt, но с недавних пор это можно делать сразу на уровне пулов ФС.
- Отсутствие дефрагментатора (zfs sync на другой zpool со сносом всех данных это дикие костыли), особенно фрагментация становится дикой на файлах с преаллокацией места (виртуалки, торренты). Да, можно слегка улучшить ситуацию если крутить настройки zfs или выделить отдельную dataset для этих вещей, но огромное количество советов по работе с виртуалками на zfs (те что я видел) сводятся к «не используйте zfs для виртуалок».
- Разбалансировка zpool если в zpool добавлять новые vdev после создания, которая за собой влечет неприятные спецэффекты вроде невозможности толком увеличить IOPS для новых данных так как они все будут писаться на один vdev
- требование резервировать свободное место иначе все станет печально с производительностью. (~10% от 8ТБ массива это аж целых 800 гигов)
В итоге пока остановился на mdadm + par2 для самых важных файлов. Ну и бэкапы само собой, хотя файлы, не защищенные par2, от всяких интересных вещей по типу bitrot они не спасут так как не инкрементальные.
1) Да, дефрагментатора не хватает, но учитывая "грядущий" массовый переход на SSD это, наверное, не так важно. По крайней мере для дома я хочу следующий NAS собрать на дешевых QLC SSD. Так как места мне много не надо.
Поэтому же мне и фрагментация не мешает т.к. пул заполнен менее чем на 50%
2) Тру, но для дома это как-то пофиг. Но добавление дисков в mdadm RAID6 это та еще боль — ребилд будет идти неделю, наверное. Причем не уверен что аварийные выключения сервака в это время оно перенесет хорошо… Но результат будет лучше чем у ZFS, это да.
В transmission есть опция, которая должна помочь решить проблему с фрагментацией закачек, "Keep incomplete torrents in".
Последние две проблемы в случае дома не должны быть значительны.
По крайней мере, в случае заполнения почти до отказа дедуплицированного SSD (вплоть до перехода в r/o загрузочного тома виртуалки из-за исчерпания места) каких-то серьезных проблем с производительностью не обнаруживалось на 0.6
Более старшие версии до такого пока доводить не приходилось.
Поройтесь на хабре — была примочка для Grasemonkey для выпиливания статей "редакторов".
Правда её придется постоянно перепиливать немного (там же их погроммистам руки некуда девать постоянно).
Но зато управлять легко: в код вшито пяток аккаунтов — и хабр становится изумительно чистым.
(правда обнаружится, что читать почти нечего — но то такое)
Не найдется. После очередного обновления лисы (69 кажись) навернулись все закладки :-)
Ищите и обрящете.
Кстати, есть под Windows: github.com/maharmstone/btrfs
«Ага!» — сказали лесорубы и пошлидальше форматировать ввосстанавливать hex-редактором опять рассыпавшийся ext2.
Не благодарите ))
del
Торвальдс подверг критике использование ZFS в Linux из-за политики лицензирования Oracle