https://www.opennet.ru/openforum/vsluhforumID3/131785.html После более двух лет разработки опубликован релиз проекта OpenZFS 2.2, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Проект получил известность как "ZFS on Linux" и ранее ограничивался разработкой модуля для ядра Linux, но после переноса поддержки FreeBSD был признан основной реализацией OpenZFS и переименован...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59930<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#276 Sun, 22 Oct 2023 17:34:11 GMT В каком месте тебе опять померещились какие-то "кластерные решения"? Мы в комментах под статьей о локальной фс. Зачем вы пришли со своей бредятиной или вам нужен наш моск?!<br><br>&gt; Что касается локальной фс, то zfs обычно не рекомендуется использовать как нативную фс под <br>&gt; кластерной фс<br><br>польским гусаром-самоучкой без мотора не рекомендуется-то?<br><br>А то вон гугль и индусские гусары с моторами (до того как их купила rhibm и выгнала на болота обратно рис содить) именно zfs и рекомендовали, и использовали для себя. (да, это более чем странная рекомендация, особенно с поправкой на время когда была дана, и я ее не понимаю, но тем не менее она была - как бы намекая нам на надежность (нет) их кластеров. И надо заметить выглядит менее дикой чем лобовое решение от ceph - которое таки имеет свойство внезапно ломаться насмерть)<br><br>(я нарочно не назову имен, посмотрим что специалист по продажам знает кроме польской методички)<br><br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#275 Sun, 22 Oct 2023 14:44:40 GMT Правильно пишут что zfs с его send / receive или с zvol over iscsi не надёжно использовать в качестве миррор или кластерного решения, слишком многое может пойти не так в реальной эксплуатации, zfs на это просто не рассчитана была изначально, например в случае сетевых сбоев или других не стандартных ситуаций может произойти всё что угодно и zfs отвалится или вообще может развалится. Для кластерных решениий нужно использовать то, что на это рассчитано изначально, например ceph, beegfs, moosefs, glusterfs.<br>Что касается локальной фс, то zfs обычно не рекомендуется использовать как нативную фс под кластерной фс, собственно об этом тоже уже вам написали.<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#274 Sat, 21 Oct 2023 14:29:02 GMT &gt; Кто тебе сказал что она нужна в качестве локальной хранилки?<br><br>да кто тебя вообще звал сюда? Мы здесь обсуждали - фс для локальной хранилки.<br><br>&gt; Просто выше объяснили, что ZFS это куча хлама<br><br>т-порылые м-ки типа тебя "объяснили". Специалисты по впариванию г-на, разбирающиеся примерно ни в чем. Куча хлама - это они и ты с ними за компанию.<br><br>И да, zvol отданный по iscsi, если уметь то и другое готовить - упирается в диски. Скорость чтения с блинов. И для этого не требуются сверхмощные клиент и сервер. Польская поделка упирается в безумную тормознутость своей реализации (причем я даже не понимаю, как они такого добились... впрочем, понимаю - у них тормозит вообще ВСЕ. От единственного metadata server до клиента с пробросом kernel-user-kernel на каждый блок, причем упирающегося в одно ядро.) Поэтому ее даже как сетевую хранилку можно использовать только если скорость конкретному единичному клиенту вообще не требуется.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#273 Fri, 20 Oct 2023 17:41:45 GMT Кто тебе сказал что она нужна в качестве локальной хранилки? Просто выше объяснили, что ZFS это куча хлама на аж 27 миллионов строк кода + выйдите за рамки локалхоста наконец и серверов может быть больше одного и там начинают на свою голову zfs over iscsi и прочее мудрить, что как раз несколько опасно на ней делать в перспективе, так как если что-то пойдет не так, то она превратится как раз-таки в мусор не подлежащий восстановлению, в отличие от той же moosefs, где есть отдельные дампы метаданных, а если испортится несколько чанков по вине того же сбойного железа, которое было не сбойным а потом стало сбойным, то вся фс не пойдет по п..... в отличие от ZFS.<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#272 Fri, 20 Oct 2023 12:25:36 GMT &gt;&gt; Ну сравнимо.<br>&gt; В принципе да, но неплохо бы уточнить конфигу железки хотя бы на <br>&gt; предмет дисков/девайсов/их параметров. А заодно и сравнение cold/hot кешей, в конечном <br>&gt; итоге 2 довольно разные случая.<br><br>-<br>&gt; # time du -sh /blabla/<br>&gt; 6.43T /blabla<br>&gt; real 2m11.230s<br>&gt; user 0m2.805s<br>&gt; sys 0m24.544s<br>&gt; Там ~ 1 млн. файлов.<br><br>Это "на холодную".<br>Второй проход - 20 сек.<br>raidz2 из 8 SATA WD Gold.<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#271 Thu, 19 Oct 2023 19:41:28 GMT p.s. а еще я на понимаю как оно с таким соотношением жора ресурсов, отвала на апдейтах кернелов и прочими потугами отожрать RAM чтобы задачам не досталось вот именно виртуалочникам зайдет. Они, вообще, реально такие существуют где-то кроме воображения опеннет-экспертов и ушибленных фанов марки?<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#270 Thu, 19 Oct 2023 19:38:38 GMT &gt;&gt; Можно и гланды, через ж, автогеном удалить если сильно приспичило <br>&gt; Это вы не к месту написали. Основное использование zvol &#8212; это как <br>&gt; раз виртуалки: отдельное блочное устройство, которое из коробки умеет thin provisioning, <br>&gt; сжатие, снапшоты, плюс даёт всё те же гарантии консистентности, что и <br>&gt; сама zfs <br><br>Проблема только в том что это начинает напоминать менеджмент БД на raw-разделах. И должно умереть жестокой смертью. По примерно тем же причинам - геморрой в администрировании на всю голову это как раз то от чего все с превеликим удовольствием избавятся, забьют в могилку осиновый кол и еще бетонными плитами обложат, отстроив саркофаг, чтобы уж точно ничего оттуда не вылезло.<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#269 Thu, 19 Oct 2023 19:36:26 GMT &gt;&gt; Можно и гланды, через ж, автогеном удалить если сильно приспичило <br>&gt; Это вы не к месту написали. Основное использование zvol &#8212; это как <br>&gt; раз виртуалки: отдельное блочное устройство, которое из коробки умеет thin provisioning, <br>&gt; сжатие, снапшоты, плюс даёт всё те же гарантии консистентности, что и <br>&gt; сама zfs <br><br>Проблема только в том что это начинает напоминать менеджмент БД на raw-разделах. И должно умереть жестокой смертью. По примерно тем же причинам - геморрой в администрировании на всю голову это как раз то от чего все с превеликим удовольствием избавятся, забьют в могилку осиновый кол и еще бетонными плитами обложат, отстроив саркофаг, чтобы уж точно ничего оттуда не вылезло.<br> https://www.opennet.ru/openforum/vsluhforumID3/131785.html#268 Thu, 19 Oct 2023 19:24:37 GMT &gt; Ну сравнимо.<br><br>В принципе да, но неплохо бы уточнить конфигу железки хотя бы на предмет дисков/девайсов/их параметров. А заодно и сравнение cold/hot кешей, в конечном итоге 2 довольно разные случая.<br><br>Т.е. если мы на холодную после ребута на файлуху лезем и весь миллион честно читаем - это одно. А если там уже основательно пошариться до этого - и половина cache hit будет, это уже другое. Хотелось бы понимать этот аспект (насколько это hot/cold случаи) для вон того замера.<br>