https://m.opennet.me/openforum/vsluhforumID3/111840.html После почти двух лет разработки состоялся (http://list.zfsonlinux.org/pipermail/zfs-announce/2017-July/000015.html) релиз ZFSonLinux 0.7.0 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Работа модуля проверена с ядрами Linux c 2.6.32 по 4.12. Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Debian, Ubuntu, Gentoo, Sabayon Linux и ALT Linux.<br><br><br><br><br>В рамках ZFSonLinux подготовлена реализация компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки проекта основаны на оригинальном к https://m.opennet.me/openforum/vsluhforumID3/111840.html#122 Mon, 07 Aug 2017 13:24:33 GMT &gt;&gt; https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/DM_Multipath/index.html#MPIO_description <br>&gt; И при чем здесь файловая система? Если это модуль для san сетей? <br><br>Специально для админов локалхоста:<br><br>1. Удивись: БТРФС - это больше, чем просто ФС! Это вполне себе полноценная система управления внешней памятью, то бишь функциональная замена РАЙДов, ЛВМ и пр., т.е. элемент САН'а.<br>2. Сюрприз - в реальном производстве (когда в хозяйстве хотя бы несколько десятков физических серверов) работать на локальных дисках дорого, ненадежно и неэффективно. Поэтому используются если не САН'ы, то хотя бы решения попроще, типа полочек с дисками. А работать без резервирования связи - ССЗБ! :)<br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#121 Wed, 02 Aug 2017 17:45:29 GMT &gt; Уборщица шваброй провод выдернула, и всё асинхронно развалилось?<br><br>наоборот же ж - реинкарнировался уничтоженный снап с частью старого содержимого унутре.<br>Ну, или в плохом раскладе - не реинкарнировался, а содержимое лежит и жрет место, и удалить его уже никак, потому что нет снапа, нечего удалять.<br><br>Но, по идее, scrub должен такое обнаружить и доудалять, а реальной угрозы диску сильно меньше, потому что в сто раз быстрее все происходит. Это если мы про ту async_destroy, что в freebsd и подобных.<br><br><br><br><br><br> <br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#120 Wed, 02 Aug 2017 14:19:40 GMT &gt; Была у меня история, как-то решил что надо наш zoneminder перенести на <br>&gt; linux + zfs, закончилось очень больно через пару дней, когда в <br>&gt; системе подходило время для удаления данных.<br><br>вы не на общеизвестные грабли с &gt;80% заполнением пула налетели, надеюсь?<br><br>&gt; обновляется на такой системе просто не вариант. Вернулись на прежнее mdadm <br>&gt; + raid0 из 4x 1TB и все по сей день летает <br><br>собственно, zfs вряд ли хорошая платформа для write-only данных, не вижу чем данное решение плохо.<br><br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#119 Wed, 02 Aug 2017 14:16:51 GMT &gt; Зря ты так, пох. Орки асинхронный дестрой в 11-ой запилили. Завидую ах <br>&gt; скулы сводит.<br><br>это тот же самый, что у delphix'а ? Так он вроде с 12го года с нами, и включен.<br>feature@async_destroy enabled local<br>(active будет если дейстройнуть что-нибудь ;-)<br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#118 Wed, 02 Aug 2017 13:58:27 GMT &gt; Вы, похоже, живёте в мире, в котором ничего никогда не меняется, <br>&gt; и никто никогда не ошибается. <br><br>работающие хранилки, которые нельзя просто увести в оффлайн и скопировать - не меняются, да.<br>Потому что ссыкотно, даже если ошиблись и получилась не очень оптимальная конфигурация, но она работает - хрен с ней, пусть уже дальше работает.<br><br>сановские разработчики думали ровно так же, во всяких гайдлайнах эта фича тоже вполне описана - десять раз подумай, семь раз отмерь, и один раз отрежь немножко. Не думаю, что вам стоит ждать изменений в этой области - оно там довольно глубоко зарыто в архитектуру, сделать хорошо и надежно не получится.<br><br>(вариант сделать ребалансинг в виде долгой _деструктивной_ операции, при обломе в процессе которой пул накрывается совсем и необратимо, разумеется, мало кому подойдет)<br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#117 Wed, 02 Aug 2017 11:55:59 GMT &gt; А какой смысл?<br><br>умеющие читать и понимать прочитанное - добавят в свою коллекцию "чего делать не надо или где надо ждать подвоха". Неумеющие - в коллекцию глупых предрассудков.<br><br>&gt; Он кстати вовсе не с большими системами связан.<br><br>вопрос не в размере, а в том, на чем именно вылезает - если как в соседнем треде "взяли хрень, сделали хрень, и потом случилась хрень", то, конечно, не очень интересно, а если на каких-то вполне обычных операциях - как раз и интересно знать, что за хрень и какие "обычные" действия ее могут вызвать. (даже если уже исправлено)<br><br>&gt; Ссылки на профильные багтрекеры могли бы подойти.<br><br>для профильного багтрекера нужно поймать баг. А у тебя на руках рухнувший массив, который даже скопировать для экспериментов не на что, оно большое, и четыре бетонных блока едут к не-очень-Чистым прудам с прошлым админом внутри.<br><br>P.S. а порно с конями-то как раз ничего не угрожает, ни разу ко мне не обращались с просьбой восстановить рухнувший lvm с ним. ;-)<br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#116 Tue, 01 Aug 2017 18:26:37 GMT а это - не мои! ;-)<br>(ну и так на самом деле меньше проблем, чем со всеми модными-недоделанными системами бинарных апдейтов, особенно, когда живешь не на releng, а на stable)<br><br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#115 Tue, 01 Aug 2017 10:08:13 GMT Вы удивитесь, но они есть.<br> https://m.opennet.me/openforum/vsluhforumID3/111840.html#114 Tue, 01 Aug 2017 06:33:10 GMT Аналогичная система крутится на FreeBSD, 12 HD камер, 2.6TB видео, старые записи чистятся каждый час, за час набегает примерно 12GB, все OK.<br>Похожая проблема с "долгим" освобождением места после удаления файлов была когда файловая система была проброшена в контейнер с помощью nullfs.<br>