Re: lightweight mail list software
Приветствую! *** Hleb Valoshka [2021-03-28 13:32]: >Учитывая, что софт для рассылок админить не приходилось, хочу спросить >у сообщества, что больше подойдёт для этой задачи. Желательно с >минимальной необходимостью в администрировании. Я бы порекомендовал mlmmj: http://mlmmj.org/ * требует только интеграции с почтовым сервером -- админится без какого-либо web-интерфейса, который ещё надо как-то запускать. Всё (адреса разработчиков) в простых текстовых файлах * одним touch control/... можно настраивать требования к тому, кто и как может писать в рассылку (надо ли подписываться или ещё чего) * умеет VERP, не будет проблем с SPF * по умолчанию не трогает Reply-To, да и вообще ничего не делает толком с заголовками, пока явно ему не будет сказано -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Tim Sattarov [2020-06-14 22:20]: >А вот кстати, что благородные доны думают про keybase.io? Лично я особо ничего не могу про него сказать, так как с ходу даже не помнил что именно это за ресурс. Ну ещё один способ получить ключ, с которым связаны всякие сторонние ресурсы. Не знаю что сказать :-). Не все захотят разглашать о себе свои связи между различными ресурсами, кто не против, то почему бы и нет. Но лично я не припомню чтобы оттуда загружал чьи-либо публичные ключи. Да и свой загружать туда смысла нет, ибо я мало на каких ресурсах имею имею учётные записи, поэтому связанных identities, кроме личного домена и подобных, не будет. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
ыдают ошибки и, возможно у меня какая-нибудь корявая версия dirmngr, но зачастую помогает только killall dirmngr и снова перезапрос ключа с KS-ов. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 14:48]: >(Да и вообще, мне казалось, что SRV указатели типа >_openpgpkey._tcp.stargrave.org из стандарта выкинули, не?) Похоже и "wkd." нету тоже теперь и вместо него "openpgpkey.": https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09 https://wiki.gnupg.org/WKDHosting -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 14:48]: >Да вот чтобы далеко не ходить — возьмем хотя бы вас. Откуда я могу ваш ключ >получить без проблем, как не с кейсервера? Из WKD? А вот шиш: WKD, как вы >совершенно справедливо пишете, опирается X.509, а ваша директория подписана >самопальным сертификатом: Keyserver -- ничем не защищённый источник (возможно PKI). WKD с недоверенным trust anchor-ом (как в вашем случае): точно такой же недоверенный источник. И в том и в другом случае вы наверняка будете использовать WoT для решения можно ли доверять полученному ключу. Плюс из DANE можно достать ещё попробовать, который возможно "защищён" DNSSEC-ом, и точно также всё равно потребует WoT например. Всё это методы получения ключа, не более. Некоторые дополнительно могут предоставлять какие-то trust anchor-ы от которых вы *возможно* сможете отталкиваться (PKI (CA для TLS, root в DNSSEC)). Keyserver не вариант: я не контролирую что там за ключ, какие подписи на нём -- любой может там поставить какую-нибудь подпись и загрузить на сервер. А мне не хочется отвечать за мусор там расположенный. Не говоря про загрузку ключей с такими же UID-ами как и у меня: конечному пользователю, пытающемуся получить мой ключ, это только геморрой. А DANE, WKD -- это то, что под моим контролем. >(Да и вообще, мне казалось, что SRV указатели типа >_openpgpkey._tcp.stargrave.org из стандарта выкинули, не?) Надо будет посмотреть. Если выкинули, то уберу за ненадобностью, поднимал то давно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 08:54]: >GPG по-умолчанию WKD для retrievingʼа¹ вполне себе использует. В том числе, >емнип, и в Дебиане. На тему разных вариантов получения ключей я как-то статью написал: https://www.opennet.ru/tips/2986_pgp_gnupg_key_sign.shtml > >Вернер Кох (мэйнтейнер GPG), когда весь этот бардак только начинался, мне >вообще сообщил, что сервера ключей не нужны, и должны умереть как класс. Тоже поддерживаю эту идею что keyserver-а не нужны как класс. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Debian 10, SSD, full disk encryption
*** Ihor Antonov [2020-05-26 11:54]: >В догонку - у меня есть пара серверов с >1 Гб оперативки, на них ZFS, все работает хорошо уже больше двух лет. Подтверждаю! И у меня тоже есть машины с 1GB RAM с ZFS-ом везде (хранилища и root), которым по 3-4 года -- работают без нареканий и проблем. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Debian 10, SSD, full disk encryption
*** sergio [2020-05-26 17:51]: >Нет, ТRIМ говорят исключительно для облегчения работы GC, а на Wear >leveling влиять возможности нет. Тут я не силён, но считал что: на wear leveling оно не влияет -- это безусловно, однако знания о неиспользуемых страницах SSD (те, которые ОС пометила TRIM-ом как "свободное место") может быть использовано контроллером SSD для их переиспользования вместо уже изношенных страниц. SSD, опять же, насколько слышал, имеют какой-то запас резервных блоков, которые заменят изношенные. Когда их запас подойдёт к концу, то при попытке записи в изношенных (а других же и нет) -- будет выдаваться ошибка. В случае же, когда резервные иссякли, но ещё есть штатно доступные свободные -- они прозрачно могут быть использованы. Свободное место на диске (помеченное TRIM-ом) как-бы приравнивается к доступным резервным блокам, что существенно может продлить работу с накопителем, если он не забивается битком. Именно поэтому и есть же рекомендация о том, что можно оставлять неиспользуемым место на SSD для резерва (хоть партицию выделить для резервивания места и не трогать её вообще). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Debian 10, SSD, full disk encryption
*** Maksim Dmitrichenko [2020-05-26 17:37]: >Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill. А я уверен что нет. Живу с ZFS-ом уже много лет на ноутбуке (сначала 4GB RAM, теперь 8GB) и не соглашусь по другому. http://www.stargrave.org/ZFS-proscons.html >Ейный драйвер и оперативки хавает больше Для кэширования, всё верно, ибо оно эффективно. Когда надо, то память оно освобождает (ну как минимум в FreeBSD). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Debian 10, SSD, full disk encryption
*** Maksim Dmitrichenko [2020-05-23 01:47]: >2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM >уменьшает безопасность шифрования. Что, прям так сильно бьет? TRIM это просто утечка знаний/информации о том что вы там что-то у себя удаляется, а также конкретные места где вы это что-то удалили. Если злоумышленник, видя ваш зашифрованный диск (как? другой вопрос), отправил вам файл по почте, файл к вам упал и сохранился на диске: он видит изменение какого-то блока (+плюс блоки метаинформации). А когда вы удалили файл, то он видит, что именно этот блок снова стал пустым и он с высокой долей вероятностью может сказать что файл удалён (или переписан, если это CoW ФС типа ZFS или btrfs). В общем, утечка метаинформации есть и тут уж каждый сам решает готов он на такую жертву пойти или нет. Лично мне кажется, что преобладающему большинству пользователей будет пофиг на подобное. Поэтому смело можно (и нужно!) использовать TRIM. Кстати, в native ZFS шифровании точно такая же проблема: подобная метаинформация тоже утекает злоумышленнику (как и кол-во используемого места например). В этой рассылке уже как-то обсуждался native ZFS encryption vs ZFS over LUKS/whatever. В принципе, LUKS/whatever (даже с TRIM) более безопасен, но тоже из серии сильно гипотетически теоретических атак на которые на практике даже внимания обращать не стоит. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Почтовый клиент и gmail
*** ugoday [2020-04-21 11:56]: >https://www.djcbsoftware.nl/code/mu/mu4e.html Тоже могу порекомендовать этот софт! Использую с ~20 GiB почты и Mutt-ом. Шустро индексирует, хорошо ищет. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Прошу помощи в bash-скрипт - кавычки
*** Victor Wagner [2020-03-11 14:50]: >Просто перл надо ВЫУЧИТЬ. В нем есть все, что есть в awk, sed и tr, и >многое-многое другое. А то приходят люди с визуалбейсковским >бэкграундом и начинают текст обрабатывать на perl с помощью функций >substr и index. Полностью поддерживаю! Плюс это всё зачастую в Perl ещё можно и в one-liner писать, заменяя sed/tr/whatever. Плюс Perl везде одинаков (+-) и его скрипты будут одинаково работать как под BSD, так и под GNU системами, в отличии от sed/grep/awk, GNU версии которых отличаются от BSD ощутимо. Плюс из коробки, без дополнительных модулей, в нём и с файлами и с сокетами можно вполне себе работать, что тоже может пригодиться. Плюс он относительно легковесен (учитывая кучу возможностей в его единственном бинарнике!) и я встречал из коробки его даже в OpenWRT каком-нибудь (ну такие вот дистрибутивы с ним попадались), да и зачастую он в любом дистрибутиве идёт из коробки, в отличии от Python/Lua/Ruby/whatever. А нежелание людей изучить ровно этот один инструмент мне не понятны, тем более, когда при этом выбирают кучу других, зачастую тоже их не зная, да ещё и страдая от несовместимости реализаций (bsd vs gnu). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Fwd: rms в России
- Forwarded message from Ineiev - Date: Tue, 11 Jun 2019 05:20:04 + From: Ineiev To: gnupg...@gnupg.org Subject: [gnupg-ru] rms в России Message-ID: <20190611052004.GA2231@desdichado> Многоуважаемые подписчики! В конце августа rms будет в Санкт-Петербурге; есть возможность пригласить его выступить в других частях России. Для этого ему нужно будет предоставить (0) помещение для лекции, (1) возможность пригласить достаточное количество слушателей, (2) оплату переезда из СПб. Приглашение следует согласовать с ним до конца июня. Благодарю за внимание! P.S. прошу переслать это объявление в другие рассылки и форумы, которым это может быть интересно. ___ Gnupg-ru mailing list gnupg...@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-ru - End forwarded message - -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: multilingual spell checker
*** sergio [2018-04-16 10:21]: >Каждый раз копируешь в вим а потом обратно? Вся работа с текстом всегда и так происходит в Vim. Ну а вообще да, если надо проверить, то скопирую в него. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: multilingual spell checker
*** sergio [2018-04-16 10:06]: >Хочу поинтересоваться, вдруг в современном мире линукс стало возможным, >проверять орфографию на нескольких языках сразу? (Как в уютном виме, который >делает так, сколько я его помню.) Лично я всю жизнь проверяю в Vim и английский и русский одновременно, в его родном spellchecker. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: актуальный софт против спама
Приветствую! *** sl...@vivaldi.net [2018-04-03 21:28]: >Кто в курсе, что на данный момент актуально для борьбы со спамом: Номер один для борьбы со спамом это проверка на reverse DNS -- работает очень эффективно. В Postfix, например, имеется из коробки. А второе это greylisting -- отсеивает бОльшую часть, но требуется (для Postfix) дополнительный демон. http://www.stargrave.org/Spam.html -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Почтовый клиент
*** Sergey Matveev [2018-03-29 21:27]: >Если канал слабый и ещё и обрывающийся, то лично я использовал бы NNCP:[...] В пятых на почтовый сервер для такой отправки писем не надо поднимать никаких POP3/IMAP4. Хотя, если предполагается использование параллельно с этим и других клиентов, то наверное придётся. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Почтовый клиент
*** Artem Chuprina [2018-03-29 15:31]: >Слабый канал и дорого — это два противоречащих одно другому условия. В >смысле, если выполняются сразу оба, то мы в жопе. И надо понимать, в >какой мы сегодня позе. Если канал слабый и ещё и обрывающийся, то лично я использовал бы NNCP: http://www.nncpgo.org/. Предполагая что почтовый сервер свой, постоянно подключённый к Интернету и принимающий почту. Чтобы с него забирать её (полностью копируя), то нужно чтобы, например, Postfix все приходящие письма отправлял через NNCP транспорт на нужный компьютер: http://www.nncpgo.org/Postfix.html как это делают с транспортом UUCP. И забирать эту почту через NNCP демон. Во-первых, будет сразу аутентифицированный и шифрованный канал (никаких TLS, SSH, VPN не надо между вами и почтовым сервером с которого забираете). Во-вторых, почтовые сообщения жмутся (zlib) перед отправкой. В-третьих, поддерживается докачка (с дешёвым (десятки байт) handshake и понимаем что конкретно надо докачать и откуда) любого сообщения. В-четвёртых, если имеется несколько почтовых ящиком для разных целей и предполагается что они разного приоритета (для почтовых рассылок один, для личной переписки другой, как минимум), то можно Postfix-у сказать чтобы с разных ящиков он в NNCP отправлял пакеты с указанием приоритета (niceness) и при связи с его демоном просасывать более приоритетные письма, только потом докачивая и продолжая работать с менее важными. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Системы управления сервером?
*** Alexander Gerasiov [2018-03-24 14:48]: >при работе с джунами очень удобно ткнуть мышой в место в >коде/диффе и написать, что тут не так и как поправить. Особенно, когда >таких мест десяток. Без этого приходится либо сажать рядом и >показывать, либо в ядерном стиле, когда дифф в почте комментируется >инлайн. >Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы. А я вот подобное делаю через самописный плагин для Vim: https://git.stargrave.org/cgit.cgi/gerrvim.git/tree/doc/gerrvim.txt Используется для работы с Gerrit, в котором есть JSON API. Суть плагина проста: открываем файлы в коммите которые нужно откомментировать, выделяем конкретные строки визуальным выделением, \cc, появляется окно с вводом комментария, и оно закрывается, сохраняя в временный файл все аггрегированные комментарии, затем запускаем скрипт преобразующий их в JSON и посылающий в Gerrit. Раньше он применялся не только для Gerrit, но для подготовки комментариев к коду и для других систем. Я много лет комментировал код, как вы это назвали, inline-ом в патчах и оставлял в виде комментария в Redmine/Trac системах. Потом не один год провёл в Gerrit, где web-интерфейс в котором можно тыкнуть на строчки и написать комментарий. Лично мне web-интерфейс не кажется удобным и нигде не видел чтобы он был удобен. Если это нужно выполнить раз в полгода, то тогда да, почему бы и нет. Но если с этим сталкиваться каждый день, если это постоянный инструмент для ежедневного ревью, то ничто не сравнится с окружением настроенным лично под себя, в удобном виде в редакторе (Vim/Emacs) и почтовом клиенте. Не бывает инструментов одинаково удобных для всех -- а web-интерфейсы это как-раз насильно диктуемая одна программа для всех. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: internet radio pleer
*** D. H. [2018-03-15 18:11]: >Ага, а лучше винил и слушать на профессиональном оборудовании а не usb >звуковухах Винил нет не лучше. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: internet radio pleer
*** D. H. [2018-03-15 17:41]: >Но при том качестве аудио файлов что валяются в сети, >воспроизводятся с ютубов и прочей браузерной ерунды разница в качестве >психосоматическая. Ну так надо качать FLAC-и и покупать CD-диски. Без сарказма. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: internet radio pleer
*** D. H. [2018-03-15 07:14]: >А зачем USB звуковушки? Ещё встречаются ноуты\десктопы без звуковых карт? Музыку вы будете слушать через встроенную звуковуху ноутбука? Через USB можно подключить качественную. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Sergey Matveev [2018-01-16 00:15]: >https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk >Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен >для использования зашифрованным dataset-ам. Статья устарела. В https://youtu.be/frnLiXclAMo где точно актуальный разработчик они L2ARC уже шифруют. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-18 21:53]: >А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если оно не сильно забито, существенно быстрее происходит чем обычного RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком диске -- он по сути делает последовательное полное чтение с одного диска и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт его последние актуальные данные и ссинхронизирует только diff. Если диск не был в зеркале, то зальёт на него только полезную нагрузку (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут записаны на зеркало). В-четвёртых, если данные испортились на каком-либо из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно известно где данные корректные и он их восстановит на втором (self-healing типа). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: тормоза ZFS
*** Alex Kicelew [2018-01-17 23:13]: >Поэтому может кто-нибудь (возможно, Sergey Matveev:) >знает, можно ли как-нибудь понять, за каким чертом он минут 5-15 читает >диск. Ух, даже не знаю что тут сказать. Вообще не могу предположить что именно ZFS мог бы делать. В фоне на долго ZFS обычно может делать только три вещи, как правило: scrub, resilver и destroy (когда async_destroy включен). На чтение из них только scrub работает. Но ARC сам по себе не будет просто так брать и освобождаться -- аналогично кэшу обычной ФС (cached поле в top/free). ARC уменьшиться в размерах только если какое-то приложение хочет памяти больше чем осталось -- тогда его вытесняют. ZFS может тупить например на секунды, допустим десятки секунд -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется что это кто-то сторонний что-то начинает делать. Я не мало работал на системах с 4, 8 и 16 GB памяти и везде с HDD. 4 GB отличаются только тем, что по-умолчанию отключен read prefetch (но он ничего не может сделать чтобы система на минуты уходила "тупить"). Нагрузки были самые разные: и sequential read/write больших файлов и PostgreSQL с десятками GB БД и MongoDB которые упирались в IOPS диска. Но везде FreeBSD/HardenedBSD. Так что может быть это какие-то косяки в Linux реализации? Хотя коллега с GNU/Linux говорит что у него на 4 GB с HDD ни разу ничего похожего на ваше поведение не встречалось. Но мне кажется что это не в ZFS дело, раз размер ARC уменьшается -- его значит кто-то другой вытесняет. Можно попробовать например кэшировать только метаинформацию в ARC, возможно только для заданных dataset-ов, выставив zfs set primarycache=metadata. Не исключено что data регулярно вытесняет metadata и диск вынужден снова и снова лезть за ней на диск. Но это мысли в слух. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
|6 TB (50%) |6 (1/VDEV) | |-+---++-++-++---| |12 |4 x 3 disk Mirror |3000|1000 |1200|400 |4 TB (33%) |8 (2/VDEV) | |-+---++-++-++---| |12 |1 x 12 disk RAID-Z1|250 |250 |1100|1100 |11 TB (92%) |1 | |-+---++-++-++---| |12 |2 x 6 disk RAID-Z1 |500 |500 |1000|1000 |10 TB (83%) |2 (1/VDEV) | |-+---++-++-++---| |12 |3 x 4 disk RAID-Z1 |750 |750 |900 |900 |9 TB (75%) |3 (1/VDEV) | |-+---++-++-++---| |12 |1 x 12-disk RAID-Z2|250 |250 |1000|1000 |10 TB (83%) |2 | |-+---++-++-++---| |12 |2 x 6-disk RAID-Z2 |500 |500 |800 |800 |8 TB (66%) |4 (2/VDEV) | |-+---++-++-++---| |12 |1 x 12-disk RAID-Z3|250 |250 |900 |900 |9 TB (75%) |3 | |-+---++-++-++---| |12 |2 x 6-disk RAID-Z3 |500 |500 |600 |600 |6TB (50%) |6 (3/VDEV) | ++ ++ |Disks|Config |ReadIOPS|WriteIOPS|ReadMB/s|WriteMB/s|Usable Space|Fault Tolerance| |-+---++-++-++---| |36 |18 x 2 disk Mirror |9000|4500 |3600|1800 |18 TB (50%) |18 (1/VDEV)| |-+---++-++-++---| |36 |12 x 3 disk Mirror |9000|3000 |3600|1200 |12 TB (33%) |24 (2/VDEV)| |-+---++-++-++---| |36 |1 x 36 disk RAID-Z2|250 |250 |3400|3400 |34 TB (94%) |2 | |-+---++-++-++---| |36 |2 x 18 disk RAID-Z2|500 |500 |3200|3200 |32 TB (89%) |4 (2/VDEV) | |-+---++-++-++---| |36 |4 x 9 disk RAID-Z2 |1000|1000 |2800|2800 |28 TB (78%) |8 (2/VDEV) | |-+---++-++-++---| |36 |6 x 6 disk RAID-Z2 |1500|1500 |2400|2400 |24 TB (66%) |12 (2/VDEV)| +----+ -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-16 08:37]: >- Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть >производительности). >- Либо я использую Gely, усложняю систему и теряю часть возможностей и >производительности ZFS. Ну насчёт заметной потери (чтобы об этом можно было думать) производительности не уверен, ну а так да -- всё верно. >- Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало. >- На них делаю два раздела поверх gely: OS и ZIL. >- SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска >всего). >- На SAS делаю Gely слой (предполагается, что все диско-специфичные >ioctl будут проброшены вниз, но так ли это?). >- Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?). Раз ZIL в зеркале, то вопрос надёжности снят. По поводу ioctl ничего не могу сказать, не задавался этим вопросом. RAIDZ какого уровня это tradeoff между кол-ом дисков сколько могут вылететь, IOPS-ами, потерянным местом -- можно и 1, можно и 2. В домашних условиях сервер же будет под "присмотром" -- поэтому вылет диска будет обнаружен во вменяемое время и заменён для resilver-а. Не забыть что и ZIL и L2ARC разделы тоже надо поверх GELI сделать. Я кстати L2ARC делаю поверх раздела зашифрованного одноразовым ключом (geli onetime gpt/SSDCACHE ; zpool add storage cache gpt/SSDCACHE.eli): после перезагрузки он конечно всё "потеряет", но зато ключи нигде не надо хранить и загружать. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-16 00:06]: >Я смотрю с другой стороны: есть пространство на SSD. Оно либо будет не >использовано, либо использовано под ZIL/L2ARC. Почему бы и нет? Согласен. Но лучше под кэш :-), лично по мне. Хуже не будет, а профит очень даже можно получить. А выделенное место под ZIL на системе где возможно вообще fsync-ов софт делать не будет -- полностью бесполезно. Ещё кстати L2ARC может использоваться для хранения таблиц дедупликации. Она требует приличных объёмов памяти (зависит количества от того как всё устроено, как данные лежат, но говорят про 5 гигабайт RAM/L2ARC нужно на терабайт данных). Сам, правда, не пробовал никогда. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
Есть вот статья про ZFS шифрование: https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен для использования зашифрованным dataset-ам. ZIL точно шифруется. В общем лично для себя я отмечаю что GELI/LUKS спокойнее как-то использовать, без вот этих вот особенностей что L2ARC будет недоступен. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-15 23:25]: >SSD на 250 Гб, чем ещё забить? Возможно, конечно, L2ARC организовать. Надо? Лично я бы точно не ZIL-ом бы его забивал и вряд ли бы вообще (если нет нагруженного PostgreSQL или Postfix какого-нибудь) под него выделял что-то. ZIL может быть абсолютно бесполезен и, как мне кажется, для большинства он таков. А вот L2ARC почему бы и нет. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-15 00:29]: >Вот это наталкивает на мысли (пусть оно и для ZIL): >"After a crash, ZFS will attempt to replay the ZIL contents. SSDs >themselves have a volatile write cache, so they may lose data during a >bad shutdown. To ensure the ZFS write cache replay has all of your >inflight writes, the SSD devices used for dedicated ZIL devices should >have power protection. HGST makes a number of devices that are >specifically targeted as dedicated ZFS ZIL devices." А, ну то бишь это как и HDD специально сделанные для NAS решений: как бы без write cache-а. Разумно. Действительно полезно. На HDD часто просто можно отключать этот write cache и нивелировать проблемы внезапного выключения. >Оттуда же (насчёт производительности): >"A key thing to know here is a ZFS vdev gives the IOPs performance of >one device in the vdev. That means that if you create a RAIDZ2 of ten >drives, it will have the capacity of 8 drives but it will have the IOPs >performance of a single drive." Для random IOPS всё верно. Sequential read будет всё же быстрее. >>> Вопрос по загрузке возникает. В Linux эта проблема решается через >>> вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? >Каким образом (FreeBSD давно был)? Нужен отдельный незашифрованный раздел? Да, просто отдельный раздел где будет загрузчик с ядром и модулями которые они подгружают. В самом man-е GELI есть примеры касающиеся boot: https://www.unix.com/man-page/FreeBSD/8/geli/ (/boot/loader.conf) -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-14 17:14]: >А что можете сказать про другие системы (NAS специфичные)? >В частности, интересует NAS4Free. Я наслышан только о FreeNAS и то что он активно используется знакомыми. Он just-works, подвохов не было. Сам руками ничего не трогал. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-14 17:14]: >Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск >данные не будут сброшены? sync=disabled даже на ZIL не запишет, насколько знаю. С sync=standard (по-умолчанию) всё как вы сказали: на ZIL точно запишет, на диск позже. >Вопрос по загрузке возникает. В Linux эта проблема решается через >вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? Про GNU/Linux, к сожалению, ничего не смогу сказать. В FreeBSD такое точно без проблем работает -- у меня схожая схема используется. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-13 21:58]: >Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на >диске нет? >В чём тогда разница? Я не понимаю про какую разницу вы спрашиваете. * zfs set sync=disabled -- означает что "не делать настоящую гарантированную запись на диск во время вызова fsync", а поместить всё в буфер и уж когда запишется, тогда и запишется. Программа после fsync думает что на диске всё есть, но при какой-то поломке/проблеме, то, что не записалось из буфера, будет потеряно * вынесенный ZIL но без зеркалирования -- fsync гарантирует что до ZIL запись дошла, на него записалась, но при поломке, то, что из ZIL не успело перенестись на диск, будет потеряно. Аналогично sync=disabled, с той лишь разницей что данные оказались на ZIL накопителе, а не в памяти Так как ZIL это SSD наверняка всегда, то SSD имеет очень не нулевой шанс внезапно отказать (а не плавно деградировать как это делают HDD) и, соответственно, шанс потерять какие-то данные после fsync. Поэтому ZIL так сильно рекомендуется зеркалировать. >Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена >система (или два SSD), и на которые будет вынесен ZIL. >Хочу сделать два одинаковых GPT раздела на каждой из SSD. >На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. >Оба раздела будут шифроваться стандартным ZFS шифрованием. >С первого раздела (миррора) должна грузиться ОС. > >Эта конфигурация жизнеспособна? Да, проблем или каких-то особенностей тут не вижу. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-10 18:18]: >Если же установлена опция sync=disabled, произойдёт ошибка записи? Если опция установлена, то не, ошибок не будет, но и fsync-а по факту не будет происходить. >0.4 % - не ахти, как много. Но такой "опции" (хранить IV) никто не предлагает для полнодискового шифрования :-). Оно должно быть максимально прозрачным и не отличимым от обычной работы. А так как IV нельзя будет хранить где-то "рядом" с сектором (всё же должно быть кратно размеру сектора), то IV будет где-то в отдельной части диска -- а это значит что регулярно нужно диском ещё и считать/писать эти IV надо будет. То есть, кроме потери места, ещё и random seek добавляется. >> Но на практике в LUKS конечно не нулевой вектор используется, а ESSIV >> (encrypted salt-sector initialization vector), что уже не предсказуемо >> для злоумышленника. >> >Но один на все блоки? Для каждого блока непредсказуемый для злоумышленника. Например вы можете просто зашифровать номер сектора на ключе неизвестному злоумышленнику -- вот и будет is good enough IV. >> Как вариант. У меня один гигабайтный диск так и сделан: ZFS поверх GELI >> поверх ZVOL-а на другом ZFS :-). Просто overhead большой, что, конечно, >> неприятно. >> >А зачем так? Основной диск с системой у меня на голом ZFS. Где-то нужно иметь зашифрованный диск (почту например хранить). Выделять отдельную партицию -- геморрой (с одним ZFS разделом удобно перенести все данные просто zfs send/recv, а когда уже несколько партиций, то начинаются пляски), когда речь о всего-то гигабайте. Поэтому проще уж, забив на overhead, сделать поверх ZVOL-а было. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-10 18:18]: >И всё бы хорошо, но про OMV вы молчите. >Что скажите насчёт ZFS+Linux? >Доводы за и против? Лично я с GNU/Linux уже давно не работаю (и не хочу) и поэтому ничего не могу сказать, так как опыта нет. Качество падает и подходы к качеству в GNU/Linux мире меня ОЧЕНЬ удручают и поэтому я в него больше "не лазаю" :-) Но это чисто личное мнение/опыт. Про OMV я вообще только от вас впервые и услышал. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Артём Н. [2018-01-10 15:31]: >Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в >итоге я всё-же куплю 2-й SSD)? Если потеряется ZIL (эта short-term область), то это равносильно тому что записи не было произведено, хотя программа получила успешное завершение fsync и убеждена что данные сохранены. >Почему? Возможно хранить список векторов в метаданных, шифрованных на >фиксированном ключе. >Собственно, там же, где хранится реальный ключ шифрования диска. Для каждого блока диска где-то хранить вектор? Если взять 2 TiB диск с 4KiB секторами, то вектора будут занимать (если считать что у нас 128-битный шифр и IV занимает один блок) 16 * (2 * 1024 * 1024 * 1024 * 1024 / 4096) / 1024 / 1024 / 1024 = 8 (GiB). Что много. Просто так ключи занимают считанные десятки байт. Но на практике в LUKS конечно не нулевой вектор используется, а ESSIV (encrypted salt-sector initialization vector), что уже не предсказуемо для злоумышленника. >Вопрос-то в другом: кроме просадки по скорости, атаку на целенаправленное >изменение данных, >без знания ключа для AES (он же использует AES по умолчанию) сложно >реализовать? На практике вообще не сложно: https://packetstormsecurity.com/files/124571/Practical-Malleability-Attack-Against-CBC-Encrypted-LUKS-Partition.html Это для CBC режима конечно же. С XTS сделать *осознанное* изменение plaintext-а уже не получится. >Да, ещё конечно имеется вариант сделать geli/luks поверх ZFS, но он мне >кажется весьма сомнительным. Как вариант. У меня один гигабайтный диск так и сделан: ZFS поверх GELI поверх ZVOL-а на другом ZFS :-). Просто overhead большой, что, конечно, неприятно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Артём Н. [2018-01-09 20:23]: >Только дорого, и начинка у меня получше будет (я так понимаю, там ASRock со >впаянным Avoton). Если так, то тогда про мать молчу. Только корпус хороший точно получается. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Артём Н. [2018-01-09 16:50]: >> > https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A >Они продают NAS в сборе, и честно говоря, я бы его может и взял, если бы уже >не собирал свой. У меня кстати именно буквально в таком же корпусе целых два своих сервера. И начинка наверное (материнская плата этой платформы) такая же как у них. Отличная платформа! Если бы мне снова пришлось бы себе NAS собирать, то я бы снова выбрал бы такое тоже. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Артём Н. [2018-01-09 16:45]: >> А, пардон: я всё это время почему-то подумал что у вас 4*4 дисков, то >> бишь 16. А это 4 четырёхтерабайтных. Да, тогда о RAIDZ3 или stripe из >> RAIDZ-ов можно не думать конечно же. Я бы наверное тоже как и вы бы >> сделал: просто RAIDZ4 из них и не парился. >> >Именно. Четыре четырёхтерабайтника. Это же не стойка, а всего-лишь корпус с >корзиной горячей замены. >В смысле? RAIDZ из 4-х дисков? Да, опечатался. RAIDZ из четырёх дисков. >> > Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, >> > производительность упадёт в четыре раза, по отношению к одному диску? >> >> Честно говоря, с ходу я пока тоже не могу понять этой их фразы. Вот >> минут 10 пытаюсь понять, но не доходит :-) >> >Однако, производительность не падает в два раза, при увеличении числа дисков >вдвое? Я думаю подразумевалось следующее: при записи на RAIDZ ZFS дожидается пока *все* диски сделают свою запись и только после этого он может делать что-то дальше. Диски, как правило, более менее одинаковые, но всё-равно разнятся по скоростям, более того: записываться то данные могут в совершенно разные области дисков -- а там время поиска/скорости могут отличаться существенно. Поэтому всегда ZFS ожидает конец IO операции самого медленного. Чем меньше дисков -- тем меньше разброс по скоростям и время ожидания. Но в целом сказано верно что в *среднем* оно как один диск, как самый медленный диск. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
потеряете ощутимо места. -a aalgo Enable data integrity verification (authentication) using the given algorithm. This will reduce the size of storage available and also reduce speed. For example, when using 4096 bytes sector and HMAC/SHA256 algorithm, 89% of the original provider storage will be available for use. Currently supported algorithms are: HMAC/MD5, HMAC/SHA1, HMAC/RIPEMD160, HMAC/SHA256, HMAC/SHA384 and HMAC/SHA512. If the option is not given, there will be no authentication, only encryption. The recommended algorithm is HMAC/SHA256. >Это да. Но во-первых, они предлагают сделать перезапись свободного места >перед созданием раздела. Но если пользователь откажется и не сделает этого, то информация о свободном месте зашифрованного раздела -- слита. >Во-вторых, это даст только сведения о записанном объёме: это почти ничего. Но это всё-равно технически является сливом информации о состоянии дел вашего диска. Я тоже считаю что это мелочи которые преобладающему большинству до лампочки и о которых можно не париться. >Да, в этом был вопрос: насколько незашифрованная метаинформация облегчает: >- Оффлайновую дешифровку. >- Возможность оффлайнового изменения файлов (в т.ч. системных). Ни тому ни другому часть незашифрованной ZFS не поможет ни на йоту. Замечу, что если вы сделаете обычный GELI/LUKS, который без аутентификации, и поверх ZFS, то злоумышленник, изменив шифротекст на диске, на сможет это сделать так, чтобы все контрольные суммы/хэши в низдежащем ZFS так остались корректными -- поэтому scrub в зашифрованном диске вам скажет что целостность данных нарушена. Поэтому по поводу аутентификации GELI/LUKS при использовании ZFS внутри них я бы не парился. scrub ничего не скажет если злоумышленник поменял незадействованные данные внутри диска (пустое место). Родное ZFS шифрование делает не просто какой-нибудь CBC/XTS, а аутентифицированное шифрование CCM/GCM -- поэтому там аутентификация данных явно проводится и он явно скажет что именно аутентичность нарушена, а не просто целостность. Ведь если злоумышленник имеет доступ к ZFS (но в которой родное шифрование), то он может в принципе изменить данные и пересчитать все хэши, чтобы, с точки зрения scrub всё выглядело так, что целостность не нарушена. Но изменить аутентифицированный шифротекст он, само собой, не сможет. Это ведь кстати ещё один плюс в сторону родного шифрования: с GELI/LUKS у вас может сыпаться жёсткий диск и действительно нарушаться целостность, а может быть и злоумышленник данные подменивает -- с ними вы этого не узнаете. А включать аутентификацию GELI/LUKS -- дорого, так как для каждого 512/4096 сектора придётся отбирать несколько десятков байт. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-08 04:18]: >Как известно, FreeNAS продаёт свои уже собранные аппаратные конфигурации. >И я заметил у них вот такой интересный девайс: >https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A > >Есть ли отличия от обычной SSD и, если да, то какие? Лично я про FreeNAS мало чего знаю, но удивлён что у них вот такие брэндовые штуки оказывается есть. Мне кажется что это простая SSD-шка. Даже не знаю что там может быть оптимального/специфичного для L2ARC. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-08 04:12]: >Хотя, я пересмотрел: я же не могу сделать RAIDZ2 менее, чем с 6-ю >дисками, а у меня их только 4. Ну вообще можно с 4-мя, так же, как и RAID6. Если что, то с ZFS можно играться с обычными файлами, чтобы на деле проверить. # truncate -s +2G disk1 # truncate -s +2G disk2 # truncate -s +2G disk3 # truncate -s +2G disk4 # zpool create testingpool raidz2 \ /home/stargrave/data/disk1 \ /home/stargrave/data/disk2 \ /home/stargrave/data/disk3 \ /home/stargrave/data/disk4 # zpool status testingpool pool: testingpool state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM testingpool ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 /home/stargrave/data/disk1 ONLINE 0 0 0 /home/stargrave/data/disk2 ONLINE 0 0 0 /home/stargrave/data/disk3 ONLINE 0 0 0 /home/stargrave/data/disk4 ONLINE 0 0 0 >Вроде немного, но я так полагаю, что оптимальное решение - просто >сделать пул RAIDZ из 4-х дисков (и по скорости будет нормально, и >избыточность не 33%, а 25%) и не париться. А, пардон: я всё это время почему-то подумал что у вас 4*4 дисков, то бишь 16. А это 4 четырёхтерабайтных. Да, тогда о RAIDZ3 или stripe из RAIDZ-ов можно не думать конечно же. Я бы наверное тоже как и вы бы сделал: просто RAIDZ4 из них и не парился. >Не вполне понятно другое: 'To double your read IOPS, you would need to >halve the number of "data" disks in the RAID-Z group (e.g. with RAIDZ-2, >go from 12 to 7 disks).' > >Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, >производительность упадёт в четыре раза, по отношению к одному диску? Честно говоря, с ходу я пока тоже не могу понять этой их фразы. Вот минут 10 пытаюсь понять, но не доходит :-) >Ok, вас понял. Сжатие оставляю. Кроме того, серьёзных вычислительных >задач, которые загрузят Xeon, там по-идее не будет: оно не должно мешать. У меня дома есть очень слабенький Celeron в котором я всюду и везде упираюсь в скорость SHA2/AES/Skein (вообще во всех задачах, не только ZFS) и прочей криптографии, но никогда не упирался в compression=lz4 (включай, не включай -- всё-равно упрусь в хэши). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-07 21:18]: >- Какой ZRAID лучше использовать: ZRAID2 или достаточно ZRAID? Зависит от количества и размера дисков в массиве, режимов работы/нагрузки на них, в случае с ZFS ещё и recordsize. Почему появился RAIDZ2 (или RAID6)? Потому-что размеры дисков растут быстрее чем их скорость работы. Если в массиве RAID5/RAIDZ вылетает диск, но всё начинает rebuild-ится, находится под бешенной нагрузкой. С маленькими размерами диска rebuild занимает вменяемое время. С большими дисками может занимать дни/неделю. Так как диски в основном ставят более-менее из одной партии, то вероятность что ещё кто-то кокнется из этих же дисков -- высока. А когда они ещё и под бешеной нагрузкой -- ещё выше. Отсюда и появились RAID6/RAIDZ2 где два диска могут вылететь и ничего плохого не случится. RAIDZ3 -- аналогичное продолжение, где уже три диска. В ZFS с RAIDZ ещё добавляются вопросы по эффективности использования места. В некоторых конфигурациях можно с ним потерять половину места. Советую вот эту статью посмотреть: https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz И не забывать что можно/стоит использовать не один RAIDZ массив, а stripe из нескольких. >- Имеет ли смысл использовать stripped mirror или это неоправданно >(максимум может быть 8 дисков в корзине, но пока будет 4)? Может быть оправдано. Всё индивидуально :-). >- Имеет ли смысл включать сжатие (в приведённой выше конфигурации)? Практически всегда не имеет смысла не включать его (compression=lz4). Если заранее известно что там будет только плохосжимаемые данные, то да, можно отключить. LZ4 безумно быстрая штука, которая хорошо понимает что ей суют несжимаемые данные и она оставит их "как есть" -- не будет overhead-а как от сжатия. Сжатие тут как-правило только ускорит всё: так как данных между дисков и системой надо просасывать меньше. Ну и просто приятно видеть как du для MongoDB может показать 20 GB, хотя реально в ней данных на 60 -- JSON/BSON хорошо сжимаются и получается отличная экономия RAM, как кэша ФС, ведь в ней сжатые ZFS объекты хранятся. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-07 21:09]: >А вообще есть ли смысл в ZFS на системном SSD? Ну а почему нет? Вообще почему ZFS может не иметь смысла :-)? Как минимум, бэкапы удобнее делать (snap/send/recv) и проверка целостности. >Где-то я читал, что выигрыш от переноса журнала на SSD порядка 0.3. Всё зависит от режимов работы (fsync). >Как сбалансировать надёжность хранения журнала и скорость работы с ним? По идее, если понадобился ZIL/log, то просто делают зеркало из него. То есть, в идеале, это например просто две SSD в зеркале, отданные от log. >Да ну. При хотсвопе это возможно сделать автоматически. >[...] >Чем такая схема хуже? Всё что вы написали верно. Но всё это подразумевает, что у вас *есть* ключ шифрования. Вы не можете отдать ваши диски кому-нибудь чтобы он например сделал resilver или scrub или send/recv ваших дисков. Вы не можете подключить чужие зашифрованные диски чтобы просто проверить scrub-ом их целостность. Мало ли чего бывает. ZFS некоторые задачи по обслуживанию может провести без ключа. Лично я нисколько не призываю к использованию ZFS шифрования из-за этих фич. Они не всем нужны. Так как ваш сервер домашний, то ключи наверняка всегда, как бы, под рукой и поэтому все эти фишки бесполезны. Я просто отметил в чём могут быть плюсы встроенного шифрования. >Но, фактически, такое шифрование открывает информацию, значит не >является надёжным. Это всё tradeoff как и в случае с "классическим" полнодисковым шифрованием. Например часто используется (ну когда-то, как минимум) CBC режим "сливал" данные о конкретном месте с которого началось изменение данных в пределах блока жёсткого диска. Да -- это слив данных, но надо прикидывать и оценивать чему он может грозить. Большинству пользователей он ничему не грозит и поэтому он по-умолчанию повсеместно использовался. Для тех кто готов "сливать" только факт изменения всего блока, но не конкретной позиции в нём, есть режим EME -- который делает двойное шифрование (туда-обратно), что в два раза дороже для CPU, но да -- надёжнее. Или вот GELI/LUKS по-умолчанию не предоставляют никакой аутентификации данных, так как это начнёт занимать дополнительное место, но тоже не самый безопасный вариант. Если вы сделаете GELI/LUKS диск поверх чистого, забитого нулями, то, пока полностью весь диск не будет записан (хотя бы dd if=/dev/zero of=disk-encrypted), то информация о реально используемом месте будет тоже "видна". Везде tradeoff. Это я всё к тому что не стал бы называть ZFS шифрование не надёжным. По-сравнению с LUKS/GELI -- оно больше выдаёт метаинформации, согласен (но, взамен давая "плюшки"). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Артём Н. [2018-01-07 20:12]: >Вопрос был в том, как она работает не с "голым диском"? А, пардон, всё перепутал. О проблемах с не голым диском не слышал. >Имеет ли смысл? Я планировал установку на SSD. Т.к., SSD достаточно большой, >там же хочу держать кэш/журналы ZFS, значит требуется два раздела минимум. Тогда смысла "чистого" ZFS не имеет конечно же. Держать кэш на ненадёжном хранилище можно без проблем, а вот если под журналом вы подразумеваете ZIL (который "log" в терминах zpool), то его очень желательно зеркалировать. Ну и иметь в виду, что ZIL/log имеет смысл только и только для fsync операций: если их мало/нет, то он не даст ничего. >Ладно trim, пробрасывается ли другие специфичные ioctl к диску или это будет >ioctl к geli? Тут ничего не могу сказать. >В смысле "без предоставления ключа"? Имеется ввиду, что он хранится глобально? В том смысле, что не делая аналога luksOpen/geli attach, вы всё-равно сможете делать scrub/resilver/send/recv. В отличии от полнодискового шифрования, вы будете знать сколько там реально занято места и размеры объектов. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-07 18:51]: >- ZFS более оптимально работает с голым диском (делает ioctl, определяет >диск ли это, если результат вызова положительный, выставляет оптимальные >для себя параметры работы). Будет ли работать ZFS также оптимально через >различные слои, в частности LUKS или gely? С голым диском работает без проблем. Но возможно надо будет указывать ashift параметр: http://www.open-zfs.org/wiki/Performance_tuning#Alignment_Shift_.28ashift.29 для дисков с 4KB размером блока. Где то я видел что иногда ZFS не справляется с автоматическим нахождением всех членов пула если диски переименовываются (был sda, стал sdb, итд). И давали совет всегда делать ZFS поверх хотя бы GPT раздела с label-ом. Этот label очевидно при смене контроллера/диска/backplane не будет меняться, в отличии от имени диска. Кроме того, GPT ещё и от необходимости ashift избавит. ZFS раздел в начале имеет немного зарезервированного места в которое например можно засунуть загрузчик ОС. FreeBSD например может быть полностью установлена на диск без каких-либо MBR/GPT на чисто ZFS диск. https://www.unix.com/man-page/freebsd/8/zfsboot/ Насчёт ZFS поверх LUKS слышал что люди делают и проблем не было. Сам я использую ZFS поверх GELI -- тоже проблем нет. Более того, GELI даже TRIM-ы "пробрасывает" наверх по-умолчанию, так что SSD-GELI-ZFS всё-равно будет с TRIM-ом. >- Если нет, то насколько стабильно, надёжно, изучено шифрование ZFS (по >сравнению с вышеназванными)? Выполняется ли полнодисковое шифрование или >это шифрование пофайловое (+метаданные)? Есть ли защита от cold boot >attack (как в Linux ZFS, так и в BSD ZFS)? Родное шифрование сделано вроде бы грамотно, но оно не полнодисковое. Только часть метаинформации и данные шифруются и аутентифицируются. Плюсы родного шифрования: scrub, resilver, send/recv будут работать без предоставления ключа, тогда как с LUKS/GELI, не "открыв" ключом диск, нельзя будет сделать ничего. Насчёт cold boot защиты не в курсе касательно ZFS. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: exim и greylist (!DKIM)
*** Andrey Jr. Melnikov <temnota...@gmail.com> [2017-09-19 12:41]: >> Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то >> переность его на стадию DATA ради привязки к DKIM нет никакого смысла. >Да не убивает он ничего уже давно, как и SPF. Так, только делает вид. Не соглашусь. По своему личному опыту graylisting действительно убивает огромное количество спама, очень вот вероятно что больше 90%. А SPF -- согласен, мизерное количество. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Fwd: Ау, Debian Developers!
Перенаправляю письмо из debian-russian@ рассылки в gost@, так как возможно тут есть заинтересованные в том же, или вообще разработчики Debian. - Forwarded message from Victor Wagner - Date: Wed, 2 Aug 2017 22:20:39 +0300 From: Victor Wagner <vi...@wagner.pp.ru> To: debian-russian@lists.debian.org Subject: Ау, Debian Developers! Коллеги, есть ли здесь действующие разработчики Debian? А то нужен спонсор. Дело в том, что в openssl решили, начиная с версии 1.1.0 выкинуть из дистрибутива почти все engine (и то сказать, большая часть этих engine поддерживала железяки. которые все уже давно перемерли от старости, а engine реально полезные, такие как PKCS11 или rutoken все равно развиваются как отдельные проекты). В результате под сокращение попала и реализация российских криптоалгоритмов, которая теперь тоже развивается как отдельный проект (https://github.com/gost-engine). Соответственно хочется ее пропихнуть в дистрибутив отдельным пакетом. Задаю этот вопрос в debian-russian, а не debian-devel, поскольку вряд ли за пределами России это кому-то интересно. -- Victor Wagner <vi...@wagner.pp.ru> - End forwarded message - -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Vasiliy P. Melnik <ba...@vpm.net.ua> [2017-07-16 21:55]: >далась вам эта фрагментация, сказали держать 20% свободного места и все будет >хорошо. В ZFS её легко можно получить просто медленно записывая файл. Да, можно потом сделать cp file file_ && mv file_ file, но а если файлов много и мало ли какие ещё режимы работы будут? Всякое может быть, и медленная запись файла не позволит его быстро прочитать это факт. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Alex Kicelew <arko...@gmail.com> [2017-07-16 22:11]: >правильно ли я понимаю, что худшее, что я получу при >превышении количества имеющихся чекпойнтов -- это необходимость снова >ресилверить 4 часа вместо 5 минут? Да, всё верно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Vasiliy P. Melnik <ba...@vpm.net.ua> [2017-07-16 21:59]: >> Как минимум, zpool scrub может сообщить какие именно файлы повреждены и >> из бэкапа их взять можно будет. Один раз у меня, когда внешний жёсткий >> диск начал сыпаться, как-раз scrub показал что вот такой и такой файлы >> биты -- взял из прошлого бэкапа. > >У нас наверное просто разный подход к резервированию критично важных >данных: как показала недавняя у нас ситуация с шифровальщиком - бекапов >много не бывает. И лучше разных и в разных местах Я не понял в чём она у нас разная и какой у вас подход. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Vasiliy P. Melnik <ba...@vpm.net.ua> [2017-07-16 21:45]: >так с данными лучше не поступать - проще использовать рсинк Как минимум, zpool scrub может сообщить какие именно файлы повреждены и из бэкапа их взять можно будет. Один раз у меня, когда внешний жёсткий диск начал сыпаться, как-раз scrub показал что вот такой и такой файлы биты -- взял из прошлого бэкапа. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Alex Kicelew <arko...@gmail.com> [2017-07-16 21:02]: >2) дожидаемся окончания ресилвера, однократно делаем этот диск >загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в >degraded state, но полностью работоспособный (в этом моменте я уверен не >до конца, и хотелось бы выслушать его подтверждение или опровержение); Но похожий хак можно например использовать для дефрагментации диска. Вообще с ней проблем быть не должно если всегда имеется запас достаточного количества свободного места (которое можно зарезервировать например как-то так: zfs set reservation=XXXG mypool/reserved), но всякое может быть. Так вот resilvering делается не как в RAID-е байт-в-байт, а записывая на диск сериализованное представление diff-а/данных: поэтому в зеркале на дисках данные могут лежать очень по разному и с очень разной степень фрагментации. Добавляем диск-зеркало: zpool attach mypool mydisk-first mydisk-second, ждём resilvering, потом делаем *detach* основного диска: zpool detach mypool mydisk-first -- массив не будет в degraded состоянии и в нём будет хорошо дефрагментированный диск. Процедуру можно повторить чтобы всё же оригинальный диск был в pool-е. В отличии от zfs send/recv -- не нужно систему переводить в offline, всё прозрачно работает. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Alex Kicelew <arko...@gmail.com> [2017-07-16 21:02]: >2) дожидаемся окончания ресилвера, однократно делаем этот диск >загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в >degraded state, но полностью работоспособный (в этом моменте я уверен не >до конца, и хотелось бы выслушать его подтверждение или опровержение); Да, всё верно. >Цель этих нетривиальных действий: если в процессе эксплуатации основного >диска (когда резервный отключен) на нем возникнет checksum error, есть >предположение (в котором я как раз совершенно не уверен), что когда >вечером будет подключен резервный и окажется, что поврежденные данные >есть в неповрежденном виде на резервном, zfs поправит их на основном, >как он поступает в случае, если в момент обнаружения ошибки доступны оба >зеркала. Тоже всё верно. Но есть засада. Время от времени ZFS делает checkpoint -- обновляет überblock ссылающийся на самое свежее дерево метаданных. У этого checkpoint есть, грубо говоря, timestamp, который только увеличивается. Во время вставки диска для resilvering он пытается понять не был ли он частью этого пула и если был, то он понимает насколько checkpoint-ов он "отстал" от основного. Найдя в основном поле старый checkpoint, он может создать "diff", который будет заresilverен. Но если прошло достаточно большое время, то настолько старого checkpoint-а не будет и он вынужден будет делать resilvering полностью всех данных с нуля, ведь он же не может "вечно" хранить все прошлые известные ему checkpoint-ы/überblock-и. Я точно не уверен, но вот терзают смутные сомнения что он будет хоть как-то смотреть на данные которые там всё же были -- поэтому такой старый диск для него будет как пустой. Кол-во checkpoint-ов на пуле вроде как фиксировано и что-то порядка полутысячи (где-то слышал). То есть минуты отключенного состояния он конечно переживёт спокойно, но вот часы уже навряд ли. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
*** Victor Wagner <vi...@wagner.pp.ru> [2017-07-16 21:00]: >Опасной может быть даже команда cd. >cd something; rm -rf * >Мораль - всегда проверяйте exit code команды cd, а лучше >в начале любого скрипта пишите set -e. Если делать скрипт, то я всеми руками за set -e. Опасна в вашем примере не команда cd, а rm -rf, а дальше уже действительно аккуратная проверка всего вокруг неё. >Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали, >не успев навредить. Если речь про tmux и screen, то повторюсь: нужно думать что писать, думать что автоматизируется путём интерактивного ввода. Не нужно делать из мухи слона и страдать из-за тучи shell файлов. Не нужно делать то, что может навредить. Если в tmux скриптах только cd, workon (virtualenv для python), export, su, запуск mutt/mocp/cmus/dnetc/whatever -- они не навредят, даже если что-то пошло не так. Не нужно сравнивать general purpose скрипты, и особые простые для запуска сред в tmux. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
*** Ivan Shmakov <i...@siamics.net> [2017-07-16 18:04]: > Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE > может дать доступ к Shell на удаленной машине; а может — > предупреждение о том, что ключ REMOTE не соответствует > сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer + > paste-buffer адекватно эту ситуацию обработать, IIUC, не > позволяют. Тогда я не так понял что вы имели в виду прежде. Да, хороший пример. Просто никогда такие "опасные" команды в tmux не автоматизировал. > Еще одна возможная ситуация — «внезапное» изменение умолчаний. Ну для меня это "болезнь" людей которые любят bleeding edge. Обновляться надо аккуратно, читая changelog-и софта. Хотя по ним не всегда понятно затронет ли оно "меня" или нет. В любом случае всё это настолько редкие для меня ситуации, что о них даже не собираюсь думать. > А если так, то в чем преимущество set-buffer + paste-buffer > перед, например, $ bash --rcfile=? (Предполагая, что > используется именно Bash. Думаю, иные реализации Shell > предоставляют схожие возможности.) (bash не использую, но это мелочи) Тут rcfile будет для одного интерпретатора. Если мне нужно открыть несколько окон (pane-ов в tmux) и в каждом из них что-то сделать своё, не одинаковое для всех окон, то тогда нужно написать несколько rc-файлов. Вместо ровно одного, где всё сконсолидировано -- нужно иметь и скрипт с tmux/screen обёрткой и отдельные rc-файлы. Да, можно их поместить и в один, который их сохранит во временные файлы, натравливая на них shell, но... это уже не удобно, это уже костыли. Мне надо думать как делать --rcfile, а мне хочется просто ручные действия "заскриптовать". > /Цель/ работы данного кода, как я ее понял, — дать пользователю > root-доступ, если «подключен зашифрованный диск». Нет, просто ввести "su -" и пароль взятый с диска. Если пароля нет, то он введёт пустоту и su меня пошлёт. Просто ввести su и пароль -- мне не надо никаких проверок. > Я не вижу причины, по которой некий «шлюз привилегий» не может > проверить факт /наличия/ файла — и дать root-доступ без > необходимости ввода какого-либо пароля. (Или хранения оного.) Для этого мне надо открыть документацию su/sudo/doas/whatever и смотреть может ли он это сделать. Мне этого не надо -- мне надо просто повторить мои ручные действия. Есть разница между "делать всё правильно" и сделать всё очень быстро, наколеночные макросы и простые скрипты которые экономят время, пускай даже которые упадут или не сработают. Время настройки автоматически запускаемого рабочего окружения с "правильными" подходами в виде rc-файлов, проверок на ошибки и прочего существенно больше чем просто сказать что надо интерактивно ввести. Если что-то пошло не так, то проще поправить скрипт. Тут точно так же как при работе в Vim редакторе: не всегда "делать правильно" эффективно по времени -- иногда надо делать менее эффективно, но зато с меньшими усилиями, если что, если например макрос "испорчен", то с нуля его повторить. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
Опять же, не знаю как в screen, но в tmux я активно использую штуку когда по нажатию сочетания клавиш, он мне во временный файл сохраняет содержимое текущего pane, открывает ещё один pane, а в нём команду натравленную на временный файл: bind-key u capture-pane -J \; save-buffer /tmp/tmux-buffer \; split-window 'urlview /tmp/tmux-buffer' \; delete-buffer bind-key y capture-pane -J \; save-buffer /tmp/tmux-buffer \; split-window 'vim /tmp/tmux-buffer' \; delete-buffer например я в терминале вижу ссылку и мне хочется её открыть в броузере. Нажимаю Prefix-u и мне открывается новое окно (pane) в котором urlview позволяет выбрать ссылку и нажать enter, закрыв это окно. Или хочется как-то вырезать/обработать текст который вижу на экране, но удобно сразу же в текстовом редакторе -- нажимаю Prefix-y и у меня новый pane, в котором vim с уже вставленным содержанием pane на котором я нажал сочетание. Видел use-case у пользователя с Gvim-ом: обычно всякие сообщения об ошибках компиляции в формате "filename:lineno:colno". Так вот, опять же, простое сочетание запускает sed/whatever который готовит вывод для диалога предлагающего открыть обнаруженные на экране строчки, выбрав нужную, он посылает команду ":e filename +lineno" в Gvim (он же, как бы, клиент-серверный). У меня когда-то был use-case чтобы всякие "#666" открывать в броузере как ссылку для Redmine. Я точно знаю что выбор ссылок или вот что-то сделать с отпарсенными значениями можно и в urxvt, в котором на Perl можно скриптовать, но я не понимаю зачем. Наверняка в любой системе есть screen/tmux, так почему бы это не сделать в них? Терминал может поменяться от системы к системе, а tmux всегда будет точно такой же родной с собой. Лично я вот люблю не монстров типа gnome-terminal, а что-то очень простое, suckless, типа st (st.suckless.org). А без tmux/whatever все эти хотелки требуют прожорливых огромных монстров терминалов. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
*** Tim Sattarov <sti...@gmail.com> [2017-07-16 04:59]: >У меня тоже был вопрос про разницу в предпочтениях, я в своё время начал >пользоваться screen и как то с tmux после не пошло... Я когда-то пользовался screen, но всегда, мягко говоря, ненавидел все их сочетания клавиш и вообще подходы к конфигурации. А с tmux-ом вздохнул спокойно. Но это личные предпочтения. >На что только люди не идут, чтобы не пользоваться docker-compose >(Продолжаю мощные вбросы :) ) Да уж, учитывая то, что я когда-то владел boycottdocker.org доменом :-) -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
*** Ivan Shmakov <i...@siamics.net> [2017-07-16 09:25]:
> Что понимается под «vi-like клавишами для поиска»? Поскольку
> Screen вроде бы умеет как «наращиваемый» Emacs-like поиск
> (C-r, C-s), так и «традиционный» (/, ?). Равно как и hjkl.
В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд. Хотя
это уже скорее просто перемещение, а не поиск.
> Я так понимаю, здесь запускается окно с Shell, в которое затем
> вводится $ su -? Честно говоря, я обычно $ screen 10 su -, без
> каких-либо промежуточных интерпретаторов.
Плюс оно бъётся по pane-ам, переходит в директории. Когда-то я сразу и
mutt и mocp запускал.
>$ cat < setup-slogin.screen
Тут вроде всё выглядит так, что запускается только ровно одна команда? В
tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего? На
самом деле кроме "su -" ещё и его пароль вставляется (загруженный с
зашифрованного диска -- мол если диск подключен, то это уж точно
авторизованный пользователь).
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
*** Ivan Shmakov <i...@siamics.net> [2017-07-15 20:28]:
> > Куда более удобной конфигурацией и скриптованием, хотя это наверное
> > субъективно. Существенно меньшими размерами (хотя в GNU Screen
> > больше фич, типа работы с последовательными консолями). vi-like
> > клавишами для поиска.
>
> Конкретнее?
Конкретнее что? Удобство? Вот один из скриптов, который неплохо читается.
#!/bin/sh
paste()
{
local pane="$1"
local cmd="$2"
$TMUX set-buffer "$cmd"
$TMUX paste-buffer -t "$pane"
$TMUX delete-buffer
$TMUX send-keys -t "$pane" Enter
}
$TMUX new-session -d -s root
$TMUX rename-window -t root:1 "su"
$TMUX split-window -t root:1
$TMUX split-window -h -t root:1
$TMUX split-window -h -t root:1.0
paste root:1.0 "ssh-add-mass"
paste root:1.1 "su -"
paste root:1.1 "cd /home/stargrave/work/govpn"
paste root:1.2 "su -"
paste root:1.3 "su -"
$TMUX new-window -t root:2 -n email
$TMUX new-window -t root:3 -n music
paste root:3 "cd tmp/music"
$TMUX new-window -t root:4 -n dnetc
paste root:4 "cd data/dnetc521-freebsd10-amd64"
$TMUX select-window -t root:1.0
аналогично есть скрипты которые запускают рабочее окружение:
postgresql, redis, переходят в директории, делают virtualenv (если
python проект), бьют нужным образом окна и их именуют.
> > Судя по всему к screen нельзя подключиться несколькими клиентами
> > (несколько людей смотрят в одну сессию), а это killer-feature.
Если можно, то ok.
> > Я так точно и не понял, но есть ли в screen-е vertical pane
> > разделение?
Ok, если есть вертикальный split.
Если screen всё это умеет, то тогда (не считая размера), вопрос вкуса
наверное.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине (was Xfce Terminal Emulator)
*** Artem Chuprina <r...@lasgalen.net> [2017-07-15 18:59]: >Зато у тебя будет screen/tmux vendor lock-in. Или tmux счел, что API >screen — стандарт де-факто, и поддерживает его? Терминалов -- десятки видов, а GNU screen один и tmux один. За свою жизнь я много терминалов сменил, а вот tmux не на что, ни разу. >Чем, кстати, tmux лучше, чем screen? Куда более удобной конфигурацией и скриптованием, хотя это наверное субъективно. Существенно меньшими размерами (хотя в GNU screen больше фич, типа работы с последовательными консолями). vi-like клавишами для поиска. Судя по всему к screen нельзя подключиться несколькими клиентами (несколько людей смотрят в одну сессию), а это killer-feature. Я так точно и не понял, но есть ли в screen-е vertical pane разделение? Можно ли в screen послать в любой pane какую-то последовательность клавиш, что, опять же при скриптовании, очень удобно и гибко? -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине (was Xfce Terminal Emulator)
*** Tim Sattarov <sti...@gmail.com> [2017-07-14 19:10]: >> 2. Очень полезен большой scrollback и поиск/копирование в нём; >А разве в эмуляторе этого нет ? Зачем screen ? Ни того, ни другого нет например в st терминале (http://st.suckless.org/). А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать текст, перемещаться по нему vim-binding-ами. >Мой вопрос больше, про: какая разница >- запустить терминал с кучей вкладок и перейти в нужные папки/запустить >нужную программу >или >- запустить локальный screen/tmux всё с теми же программами ? Как автоматизировать запуск обычного GUI терминала и в нём ввести всякие команды, открыть нужные табы, назвать их, итд? Это значит терминал должен поддерживать какой-то API и его надо бы вызывать. Я даже не знаю есть ли такое в них, но это будет terminal/vendor-lockin. А с tmux/screen можно заменить эмулятор терминала не трогая автоматизацию с terminal-specific API. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: NAS
*** Andrey A Lyubimets <and...@nskes.ru> [2017-07-14 05:35]: >Под ZFS Вы отключаете кэш на дисках? Или это в контексте аппаратного рэйда? Вообще конечно же отключить его не мешало бы (но мне лень :-)). Но что будет если не отключить? Если какая-то часть данных при не запишется внезапно, то всё-равно в них самым последним элементом идёт überblock, создающий checkpoint. Если его не записать, то просто не будет checkpoint-а. С точки зрения целостности системы -- абсолютно ничего страшного. Часть ZIL-а при этом может записать, а может и нет -- просто будет потеря данных за какое-то небольшое время (несколько секунд на практике, по идее). Если "разсинхронизация" из-за кэша на дисках произойдёт внутри массива, то после подключения pool всё-равно диски будут заresilverены до того, у кого самый свежий checkpoint+ZIL успел записаться. То бишь включённый кэш просто неприятен будет тем что данные даже после fsync потенциально могут пропасть, но с целостностью всего остального проблем не будет. >А насчёт комментария по ссылке, то вывод - правильный, но с этим >категорически не согласен(имхо, фантазия в чистом виде): [...] >^ mdraid выравнивает зеркала??? Да, я тоже про такое не слышал, звучит фантастически :-) >PS Что бы два раза не вставать - Сергей, спасибо за ваши посты по zfs. >Вам стоит их причесать в статью и опубликовать - прослыть евангелистом zfs Спасибо! О статье я как-то думал, но всё не решался ещё. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине (was Xfce Terminal Emulator)
*** Tim Sattarov <sti...@gmail.com> [2017-07-13 21:20]: >On 13/07/17 03:40 AM, Igor Savlook wrote: >> Постоянно использую tmux на локальной машине с xfce. Вообще без него >> жить немогу. > Интересно послушать сценарий, когда это может пригодиться В терминале он предоставляет табы (tabs) и scrollback историю с поиском, плюс с удобными Vim клавишами навигации по ней -- можно использовать какой-нибудь простой терминал типа st (http://st.suckless.org/), множество буферов (а не один X11-овый), возможно заскриптовать запуск рабочего окружения (простым shell-скриптом задать как надо побить окна, именовать их, предварительно выполнить команды, итд). Я тоже не представляю жизни без tmux-а локально запускаемого ибо очень удобно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: zfs on linux
*** Artem Chuprina <r...@lasgalen.net> [2017-07-13 12:58]: >Почитал тут подробно Aaron Toponce's ZFS on Linux User Guide >(https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/) Спасибо за ссылку. Возможно лучшая документация по ZFS для незнакомых с ним прежде которую я встречал! >И что, вот прямо реально если, допустим, что-то сдохло и система не >грузится, то воткнуть диски в другую машину и импортировать пул >невозможно, привет всем данным, которые там были? Или все-таки -f и -F >(ман гуглится от FreeBSD, а систему с zfs я еще не поставил) у нас тоже >есть и работают? Если pool не был экспортирован, то другая система при импорте действительно скажет что он "занят", но под FreeBSD force опция без проблем его импортирует. Я не знаю даже гипотетически к техническим проблемам каким оно может привести -- я думаю это исключительно чтобы предупредить человека, на всякий пожарный, мол вдруг он нечаянно что-то не то хочет сделать, мол явно не сказали export pool, может он нечаянно хочет и import сделать. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** Artem Chuprina <r...@lasgalen.net> [2017-07-09 21:57]: >Я косым взглядом вижу в описаниях ZFS фичу проверки контрольных сумм и >восстановления при сбоях отдельных блоков. Но вижу ее в контексте RAIDZ, >а его, соответственно, в контексте нескольких дисков. Вопрос. В >контексте одного диска такая фича есть? Надо ли ее как-то специально >включать, или она вообще у ZFS по умолчанию? Важные данные (метаинформация) хранится на ZFS в двух экземплярах, очень важные данные (описания ФС и тому прочее) -- в трёх. Если где-то будет нарушение целостности, то будет смотреться копия. Просто сами данные по-умолчанию хранятся в одном экземпляре и zfs scrub сможет показать что их целостность нарушена, но, естественно, восстановить не сможет. Но если сделать zfs set copies=2 mypool/myfs, то и данные будут в двух экземплярах (можно и 3) и тогда их можно восстановить. Само собой, это потребует в два раза больше места, но восстановить ZFS сможет побитые. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: zfs on linux
*** Alex Kicelew <arko...@gmail.com> [2017-07-09 19:10]: >Хм. На большом компе я планировал бэкапить только нужные мне вещи, а вот >на ноуте думал сделать копию единственного диска и ежедневно сбрасывать >на нее send-ом наболевшее за день, чтобы при крахе основного винта >просто с нее сразу же загрузиться, а уже потом докупать еще винт. Вы >полагаете, что эта идея (под линухом, фри у меня нет) мертворожденная? Лично я не вижу какое будет отличие GNU/Linux ZFS-а от *BSD-ного. zfs send/recv же будет работать точно так же. Идея делать инкрементальные бэкапы (хоть каждый час по cron) мне нравится. Точно так же делал на ноутбуке где SSD-диску 3.5 года и от него всего можно ожидать. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: zfs on linux
*** Alex Kicelew <arko...@gmail.com> [2017-07-08 13:55]: >Эта проблема решена. Вероятно, дурак -- я, а не zfs (хотя я до конца так >и не понял, в чем именно). Причина была в том, что я устанавливал zfs на >диск, подключенный по usb. На диск, вставленный в гнездо, все >поставилось нормально. Правда, не работает... :( Я как-то встречал один USB<->SATA контроллер (внешний контейнер) который действительно чуть "смещал" данные. То есть диск выглядел как немного уменьшенный по размеру. Данных вроде туда не писал никаких дополнительных, но вот почему-то геометрия была чуть другой. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Oleksandr Gavenko <gaven...@gmail.com> [2017-07-07 18:51]: >Интересно, восстановление в случае упавшего диска в ZFS также затронет только >используемые блоки? Ведь эта оптимизация на уровне FS, где присутствует >необходимая информация. Это должно сэкономить время восстановления в 2-3 и >более раз в зависимости количества "свободного" места... Да, оно так и делается. Если на терабайтном pool-е будет всего-лишь гигабайт полезных данных, то будут перегоняться/resilverится только этот гигабайт данных. Однако если заполенность RAIDZ/mirror становится большим (80% и более), то оно уже запросто станет медленнее чем классический RAID. Обычный RAID последовательно читает/пишет, а RAIDZ/mirror много random access-а создаёт который по времени будет дольше. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: NAS
*** Stanislav Vlasov <stanislav@gmail.com> [2017-07-07 08:40]: >А то raid6 из 8 с ним давал порядка 100 МБ/сек при наличии батарейки, >а raid6 mdadm на тех же дисках в том же сервере - порядка 400 МБ/сек. Действительно, все тоже мне встречаемые железные RAID-ы, возможно кроме очень дорогих и топовых, на RAID6 всегда были медленнее чем mdadm. RAID5 вообще только XOR операцию использует, а вот RAID6 уже тяжёл и требует процессора. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Tim Sattarov <sti...@gmail.com> [2017-07-07 00:20]: >А если там был RAIDZ ? и я в группу из 1ТБ дисков добавляю ещё один 2ТБ >Будет ли весь объём использован ? Будет использован 1TB из него. Когда все диски будут заменены на 2TB, то тогда станет доступно по 2TB со всех сразу. >Или, будет ли у меня возможность добавить две партиции по 1ТБ на этом >диске ? Будет. ZFS пофиг что добавляется: диск ли это (sda) или партиция (sda1) или там какой-нибудь iSCSI или вообще просто путь до файла, который будет как-бы жёстким диском. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: NAS
*** Tim Sattarov <sti...@gmail.com> [2017-07-06 23:22]: >Не, ну блин >USB3 максимальная скорость 5Gbps >SATA3 максимальная скорость 6Gbps Ну для подключения одного жёсткого диска-то это как-раз не важно. Сколько современные диски вытают скорость? 150-200 MBps, а это 1.2-1.6 Gbps. Но если конечно несколько дисков пойдут по одному "проводу", то тогда можно и упереться в 5-6 Gbps. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Tim Sattarov <sti...@gmail.com> [2017-07-06 23:04]: >это может быть я выдаю желаемое за действительное, но моё понимание >было, что ZFS работает с JBOD на бэкенде и собирает массивы дисков, так >же как LVM. Что-то типа того. >сейчас я вижу требование о равных размерах томов и пересборке vdev. Не равных, а не меньших. И статья о том чтобы увеличить размер VDEV-а, сделать expand. Если в VDEV-е два терабайтных диска, то один можно заменить на 2TB, но размер VDEV останется всё-равно 1TB. Но если второй диск заменить на 2, то только тогда VDEV станет равным 2TB. В статье и говорится что нужно поочерёдно каждый диск в VDEV заменить на большего размера и только тогда место станет доступно. >делаю я ноду в AWS, скажем с четырьмя терабайтными дисками и страйпом. >вопрос номер раз: как делать страйп ? все диски в один VDEV ? или лучше >каждый диск в свой VDEV и потом его в страйп на уровне zpool ? Pool это, грубо говоря, RAID0, stripe. Каждый VDEV это stripe элемент. Поэтому сделать stripe можно только добавив каждый диск как отдельный VDEV. Из коробки это собственно и делается проще всего: zpool create mypool da0 da1 da2 da3 -- stripe из четырёх дисков. Внутри VDEV-а можно сделать только mirror или raidz. >Хочу ускорить доступ к данным и пользоваться ephemeral SSD, напрямую >подсоединенному к хосту (супротив остальных дисков, которые HDD и вообще >говоря сетевые). В силу эфемерности SSD диска, каждая холодная >перезагрузка (power cycle) его обнуляет. >Где хранится информация, что /dev/xvdf надо использовать как кэш ? >на самом диске или вне его ? >насколько просто и быстро добавить обнулённый диск, нужна ли какая то >инициализация ? РАз ускорить и использовать SSD, то это значит добавление cache диска, L2ARC, в терминах ZFS. Вот насчёт таких кэшей не знаю точно, вряд ли тут особенность, но в ZFS полностью вся конфигурация хранится на самих дисках, на всех членах pool-а. Сам не делал, но думаю что после перезагрузки zpool status скажет что один из дисков, который cache, недоступен. По идее достаточно будет сделать zpool replace mypool blablabla-diskid /dev/xvdv -- то есть сказать чтобы он заменил отсутствующий диск. Раз это кэш, то никакого resilvering не надо и он сразу должен быть в строю. Отсутствующий диск в зеркале или raidz заменяется этой же командой, но для них уже делается resilvering, который равносилен переносу всех полезных данных на новый диск. >Когда я решу увеличить размер пула, можно ли просто добавить весь набор >новых дисков ? То есть были 4 по терабайту, добавляю 4 по 2 ТБ и после >синхронизации удаляю старые 1ТБ. Да, это делается без проблем. Причём добавить их можно сразу все пачкой, не дожидаясь resilvering-а на каждый по отдельности последовательно. Одно но: zpool по-умолчанию имеет (в FreeBSD, по крайней мере) zpool set autoexpand=off и после добавления дисков, zpool status покажет в столбце EXPANDSZ размер до которого можно expand-ить pool. Expand, судя по man, делается zpool online -e командой, но я, если честно, уже забыл как точно, ибо делал один раз. >Куда лучше добавлять, в существующий VDEV или создавать новый ? А если >каждый диск был отдельным VDEV ? Создать новый VDEV можно только добавив его в pool. А это равносильно добавлению stripe диска. VDEV из pool-а невозможно "вытащить", так же как и диск из RAID0! Если вы сделаете zpool add, то ни старый диск, ни новый уже нельзя будет достать. Я так один раз (по незнанию) вместо zpool attach сделал zpool add и пришлось zfs send-ом сбрасывать все данные на третий диск и с нуля создавать массив, zfs recv-ом восстанавливая данные. Тут только zpool attach-ем можно делать. Если каждый диск был отдельным VDEV, то значит каждый новый диск добавить по одному к своему VDEV-у. То есть должно получится 4 VDEV-а, как и прежде, в каждом из которых по два диска. После resilvering-а, каждый старый диск можно из каждого VDEV-а zpool detach-ем убрать. zpool add -- добавление stripe VDEV-а zpool create mypool da0 da1 -- создание mypool с stripe из двух дисков zpool attach -- добавление зеркала в текущий vdev zpool create mypool mirror da0 da1 mirror da2 da3 -- создание mypool с stripe из двух зеркал (da0+da1 и da2+da3) zpool create mypool raidz1 da0 da1 da2 raidz2 da3 da4 da5 da6 mirror da7 da8 da9-- создание mypool с stripe из трёх элементов: raidz1 с тремя дисками (0/1/2), с raidz2 с четыремя (3/4/5/6) и зеркалом из трёх дисков. Добавлять VDEV в zpool можно и позже, когда угодно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: NAS
*** artiom <artio...@yandex.ru> [2017-07-06 22:46]: >А тут не вопрос скупости: стоить это будет примерно одинаково. >Скорее, целесообразность. Потому, что мне решение с юсб, хоть и >показалось маргинальным, но убедительных аргументов в пользу сата я не >смог найти. У меня только мой опыт есть в этом вопросе и я не задумываясь бы, при схожей цене, делал бы SATA. Помнится, была даже *серверная* Intel плата, но, правда, с ещё 32-х битным процессором, довольно старая, и там USB устройства просто время от времени отключались и подключались снова (судя по сообщениям в dmesg). Аналогично было с подключением дисков к десктопным материнкам или ноутбучным. Не исключено что проблемы были в SATA<->USB контейнере, хотя их поменялось три. Без нагрузки, работало сносно, а как дать активные IO операции, так слетало. SATA для меня прост: или работает или нет (если провода/контакты в порядке, такое бывало). Плюс, насколько понимаю, USB подсистема жрёт больше CPU ресурсов в ядре, чем SATA. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: NAS
*** artiom <artio...@yandex.ru> [2017-07-06 22:28]: >Возможно использовать USB 3 вместо SATA, у этого варианта даже есть свои >плюсы, да и по пропускной способности интерфейс подходит. >Вариант? Лично я на всяком железе (не серверном, "простом" домашнем) делал не раз всякие простые шлюзы в Интернет и NAS-ы, но всегда так случалось что работает оно, как бы, нестабильно. Бывает что USB устройство отвалится и снова появится. Лично я вот для себя уяснил что скупой платит дважды :-), и я бы не стал делать на USB ничего, разве что загрузиться с неё например. Но это лично мой опыт -- USB фигово работает, а SATA без проблем. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Tim Sattarov <sti...@gmail.com> [2017-07-06 21:21]: >> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в >> опасности, вставьте диск чтобы на него произошёл resilvering и не было >> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает, >> то в системе, с точки зрения user-space, абсолютно ничего не происходит, >> всё прозрачно и никто кроме zpool не знает что что-то не так. >А как это соотносится с вот таким взглядом на "удобства" ZFS ? > >http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html А что тут про соотношение? Статья по ссылке расказывает про то, как увеличить место в pool-е, как добавлять жёсткие диски к нему. У меня написано про замену дисков в pool-е, когда они выходят из строя -- там можно добавлять какой угодно диск, лишь бы был не меньшего размера, а resilvering на него пройдёт. В статье сказано всё верно. В ваших руках компромисс между теряемым местом в пределах одного VDEV (сколько дисков вы хотите за "раз" объединить в один RAIDZ) и количеством VDEV-ов внутри одного pool. Вы можете сделать pool с 1 vdev-ом RAIDZ из 8 дисков, либо pool из 2-х vdev-ов, в каждом из которых по четыре диска. В первом случае, как в статье сказано, вам нужно будет заменить все 8 дисков, чтобы увеличить место, а во втором достаточно только половину, чтобы увеличить один из vdev-ов. Позже всегда можно будет заменить диски внутри и второго vdev-а. vdev это один "уровень" RAID, а объединение vdev-ов в pool это второй, striping. Это если в терминах классических RAID-ов. ZFS получается из коробки сразу же двухуровневый RAID. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Artem Chuprina <r...@lasgalen.net> [2017-06-26 17:21]: >Хотя идея, что для хранения данных _на диске_ >нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что >для хранения кошечек это, пожалуй, overkill. На гиге ZFS работать будет. Чисто для хранения/чтения подойдёт. У нас тут упоминалось по пять гигов на терабайт -- это если дедупликация нужна. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Oleksandr Gavenko <gaven...@gmail.com> [2017-06-26 14:11]: >Или поступать как с лентами - попеременно между лентами гонять данные, что бы >освежать намагниченность? Мне кажется что этот вариант хорош. Чисто чтобы поддерживать намагниченность. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** yuri.nefe...@gmail.com <yuri.nefe...@gmail.com> [2017-06-25 18:34]: > У меня SSD умер сразу в одночасье. Сразу получил нерабочий кирпичик. > Но я сильно не упорствовал, мне по гарантии его поменяли. > > SMART для SSD не внушает доверия. > Скажем, вот вывод smartctl для ноутбучного SSD (ему более 4 лет): Ого, сколько у вас информации (пускай и не очень доверяемой). У меня только power on hours (честно говорит что 3.5 года), power cycle count и температура. Спасибо за информацию! Собственно, подтверждается то, что он дохнет сразу, в отличии от HDD. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** alexander barakin <a...@barak.in> [2017-06-25 16:50]: >а оно простым смертным разве продаётся? гуглояндекс ничего мне не >рассказал по этому поводу. Я покупал две такие железки в компании ETegro Technologies много лет назад, но такой компании уже не нет. Физическим лицами они продавали без проблем. Я к тому, что такие железки существуют. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 16:27]: >Так рейд поломан будет, он же собраться не должен. То есть, при внезапной поломке, мы понимаем что данные неконсистенты и считает что проще всё восстановить извне, типа как-будто это равносильно пропаже данных? Ну... как вариант, всё-равно лучше чем ничего, чем без RAID. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 16:22]: >В три датацентра данные реплицировались, в одном машина сдохла. >Вопросов о консистентности не стоит. Пропажа данных, недоступность -- это одно. А когда вот у вас лежат данные, а вы даже не подозреваете что они испорчены. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Artem Chuprina <r...@lasgalen.net> [2017-06-25 16:05]: >Это понятно. Важно, что его не требуется выделять заранее, на этапе >разбиения на диска разделы, как в случае с LVM. Не, не, не, боже упаси эти snapshot сравнивать с LVM-ными :-)! Эти снапшоты идентичны по сути созданию тэга в Git-е. Вы находитесь на каком-то коммите (каком-то состоянии текущем ФС) и делаете git tag -- замороженное текущее состояние данных (и snashot ZFS это просто снимок, замороженное представление). Ещё есть клоны: тоже самое что и snapshot-ы, но на них можно писать. Это уже аналог git branch команды. >При этом, если несколько последовательных снапшотов, и я удаляю >промежуточный, оно может освободиться, а может перераспределиться на >предыдущий? Или там промежуточный удалить вообще нельзя? Промежуточный можно удалить. Это, опять же, как git branch-и. Место "перераспределится" на следующий за ним snapshot, ведь чтобы держать его данные ему ведь до сих пор нужна та дельта. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 16:05]: >Короче, под почту и логи он не подходит явно. Просто выставьте размер записи не по-умолчанию в 128 KiB, а 4 или меньше. >А, вот оно как... >Но при создании ФС я задаю размер? >Просто могу расширить в будущем, если место в пуле есть? Нет, размер ФС вы не задаёте, он просто берётся из pool-а. Это, как-будто, вы создали просто директорию -- место для неё берётся из того что имеется. reservation это действительно резервирование места, его можно задать когда угодно. В ZFS в 99% времени используют только две команды: zpool и zfs. zpool это управление железными дисками, массивами и тому прочим. Это pool -- штука которая что-то там может как-то хранить. А поверх этого хранилища уже создаются высокоуровневые файловые системы ZFS, командой zfs. Место pool-а из коробки доступно всем созданным ФС: # zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 37.1G 49.1G 5.95G none zroot/home 9.50G 49.1G 6.99G /home zroot/home/tmp 2.19G 49.1G 2.19G /home/stargrave/tmp это вот у меня говорит что для трёх ФС (zroot, zroot/home, zroot/home/tmp) доступно одни и те же 49.1 GB. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** Artem Chuprina <r...@lasgalen.net> [2017-06-25 15:57]: >Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень >смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на >нормальном винте такой же раздел с копией. После того, как у меня пару >раз на ровном месте побились существеные для работы системы файлы, я SSD >из употребления вывел. И затаил... Хочу поинтересоваться: а как умирают SSD диски? В SMART-е они об этом предупредят? Сыпятся частями или сразу полностью? У меня SSD в ноутбуке уже 3.5 года живёт и нагрузка на нём всегда была очень высокая (развернуть 20 гигабайтный PostgreSQL с индексами, по несколько раз в день) и по идее уже давно должен бы был помереть. Если он летит частями, то zfs set copies=2 должно помочь от того когда придёт судный день чтобы успеть сдампить данные на что-то работающее -- это хоть как-то бы успокаивало. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** Artem Chuprina <r...@lasgalen.net> [2017-06-25 15:40]: >В zfs есть понятие "переключиться на такой-то снапшот" в смысле сделать >так, что в качестве основного состояния FS будет подключен он? И оно это >запомнит через перезагрузку? Если так, то это интересно... Во-первых, можно просто откатить состояние ФС до заданного snapshot: # zfs rollback mypool@snapshotname Во-вторых, любой snapshot по-умолчанию доступен ещё и вот так, без необходимости делать rollback: /mypool-mountpoint/.zfs/snapshot/snapshotname Ещё есть zfs diff команда, которая может показать diff, с точки зрения файлов/директори: # zfs diff zroot@backup M / M /boot M /var M /root + /var/run/clean_var + /var/spool/lock/clean_var + /var/run/ld-elf.so.hints + /var/run/ld-elf32.so.hints + /entropy [...] + /var/log/Xorg.0.log.old - /var/log/Xorg.0.log Причём делает она это быстро, опять же из-за деревьев Меркле внутри ZFS. > > 8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если > > хочется включить дедупликацию, то, личного опыта нет, но говорят что > > нужно примерно 5 гигабайт RAM на каждый терабайт данных. То есть в > > случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию > > можно включить на уже работающей системе, когда угодно, как и выключить. > > А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука > > я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а > > вот дедупликация... я за несколько лет так и не смог увидеть в домашних > > условиях где бы это могло помочь. > >Хотелось бы понять, точно или нет. У меня, например, одни и те же >фотографии в некотором количестве хранятся в архиве оригиналов (на >сервере), у жены на виндовом компе, где она их отбирает и обрабатывает >(обрабатывает не больше трети), откуда попадают в бэкап на тот же >сервер, у меня на ноуте, и тоже в бэкап, и на планшете, откуда, опять же >в бэкап. Суммарный объем копий на компе жены измеряется не меньше чем >десятками гигабайт. По идее, не очень много, но интересно было бы >поэкспериментировать. Если бы много, то от 2 до 4 копий - это уже вполне >повод для дедупликации, но вроде на фоне остального не шибко дофига. С дедупликацией не хватит 8-ми GB. А без неё работать точно будет. "Выжмет" ли оно всё из дисков -- надо смотреть, но мне кажется что без проблем, если речь о перегонке/хранении фотографий. >Там поблочные дельты хранятся или пофайловые? Грубо, если файл >переименован, снапшот будет отличаться только инодом, или блоки тоже >отделит? Будет отличаться только инодом. Из-за хэш деревьев он прекрасно понимает какие части дерева изменились. Если в гигабайтном файле изменился только один килобайтный кусочек, то, грубо говоря, diff будет хранить только этот кусочек (или кусочки). >А кстати, раз в ZFS можно на ходу включить и выключить дедупликацию: >возможна ли эпизодическая ручная дедупликация? Т.е. чтобы включил, она >отработала, выключил (а то памяти мало для ее постоянной работы), а >результат остался? Сам не пробовал, но ничего не мешает так сделать. Сам тоже об этом как-то думал. Дедупликация это ведь всего-лишь нахождение общих данных и создание ссылок на один и тот же блок, убирая ссылки на дубликаты. Можно включить: он переиначить ссылки на блоки, потом отключить. Как вариант, можно сделать zfs send с опцией -D, которая создаёт дедуплицированный поток сериализованных данных, а потом восстановить с них. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 14:06]: >> Бывает внезапная поломка backplane, контроллера, блока питания, >> материнской платы, итд. >> >Не поможет тогда контроллер. Ну в случае выхода контроллера -- да. Если backplane или что-то остальное, то поможет -- запустить на работающей системе. >К тому же, это для каких-то очень критичных систем. >А там, как правило, данные по нескольким разным машинам/датацентрам >реплицируются, и проблема тоже не сильно актуальна. Проблема того что у вас есть возможность получить неконсистентные данные, испорченные. По моему это очень критично, независимо от задач. У нас же ЭВМ, куча миллиардов инструкций, гигабайты хранилищ, а данные могут быть потеряны... не порядок это. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 14:04]: >/var не на отдельном разделе? Это вообще отдельная директория (не /var) на зашифрованном разделе. >Он упаковку мелких файлов в один блок, как reiserfs, умеет? Он может динамически менять размер блока (как конкретно -- не знаю). Но нет, в один блок засунуть несколько "данных" не может (как ещё кстати и XFS умеет). >Ok. Но он его будет использовать для своих нужд? >И что будет, когда квота выйдет, просто скажет, что места не осталось? Да, на системе для которой место не было зарезервивано он скажет что места не осталось. Тут резервируется место для filesystem, но свободное место для проблемы фрагментации должно быть не на filesystem, а на pool-е. Pool может содержать несколько filesystem (всё это термины в контексте ZFS). Поэтому это место на пуле будет использоваться само собой, оно не прикасаемое. reservation это просто квота для отдельной filesystem (грубо говоря, директории). >А этот RAIDZ (пока не почитал про него), он и есть срайп с контрольными >суммами? Грубо говоря, да. Аналогично RAID5/6. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 13:49]: >Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП. Бывает внезапная поломка backplane, контроллера, блока питания, материнской платы, итд. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 13:53]: >А если я хочу часть памяти под другие нужды? >У неё квоты есть? Через sysctl можно ограничить максимальный размер ARC-а (кэша ZFS). Например для PostgreSQL на ZFS как-раз и дают такой совет, чтобы ZFS не отхапал себе лишнего, более полезного для СУБД. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 13:47]: >68% фрагментации, вы это серьёзно? Я сам не знаю как это интерпретировать. Возможно это связано как-то и с размером записи (recordsize) по-умолчанию. На этом разделе в основном только почта в maildir формате. recordsize стоит в 128 KiB. Видимо то, что каждое сообщение по-умолчанию пихается в такой большой блок и приводит к таким цифрам. Ибо уж после zfs recv команды фрагментация должна быть нулевая, так как поток после zfs send полностью сериализован, но на деле он так не показывает. Всё же на это разделе фрагментация как мы (пользователи не ZFS) её понимаем вообще нулевая, но из особенностей только тысячи тысячи маленьких файлов и recordsize=128KiB. >Я понимаю, но это значит, что надо за процентом заполнения следить. Либо сделать раздел у которого зарезервировать нужное кол-во места. Есть zfs set reservation команда. >Кстати, а как оно распределяет большой файл по дискам в пуле (в разных >режимах)? stripe-ом по возможности старается, чтобы распараллелить чтение/запись, как и RAID. Если зеркало, то само собой чтобы копии на двух дисках. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** Vasiliy P. Melnik <ba...@vpm.net.ua> [2017-06-25 12:11]: >действительно, чем больше - тем лучше, потому как сожрет все, что есть, но >мало памяти - просто медленнее работает. Никаких крашей это не вызывает Тут ещё особенность самой фри очень любить память и своп. Linux будет свопаться (по-умолчанию) только если реально что-то начинает не умещаться в память и её никак не освободить. А FreeBSD по-умолчанию просто ради обычного кэша ФС (даже без ZFS) может выгрузить процесс в своп, потому-что он давно не просыпался (какой-нибудь демон надолго уснувший и ничего не делающий). А так в ARC кэше ZFS есть MRU (most recently used), MFU (most frequently used) участки кэша. Любое чтение/запись данных их всегда поместят в MRU раздел и поэтому память всегда будет вся забита хоть чем-то. >З.Ы.повелся на бтрфс - ну типа линукс, зачем у него тянуть инородное, есть >же родное. Очень не доволен, не нравится скорость работы. Сравнить пока не >с чем - 7 терабайт бекапов тяжело перекинуть куда-то, чтобы перекинуть на >зфс Btrfs не умеет аналогов RAID5/RAID6 (в ZFS RAIDZ1/2/3), не умеет выделенных дисков для кэша второго уровня (flashcache аналог Linux) -- что говорит что он не для серьёзного enterprise. Ну и вместо криптографических хэшей используется CRC32C, насколько вижу по Wikipedia... лично по мне, так это основной аргумент почему я даже не смотрел бы в их сторону. Доверять целостность не криптографическим хэшам я не могу. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** Igor Savlook <i...@alzari.pw> [2017-06-25 11:56]: >15 минут более чем хватит, следуя твоей логике также может отказать и >аппаратный raid что тоже повлечет за собой крах массива и упаси чтобы >этот аппаратный raid был vendor-lock В дорогих моделях контроллеров я видел что есть SSD и RAM подпитываемая суперконденсатором или батарейкой. Её хватает как-раз для того чтобы из RAM сбросить информацию на SSD. Есть модели где только SSD встроена -- там о потери питания не беспокоимся. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Стратегия поддержания резервных копий. Деградация носителей.
йл, в который при zfs set sharenfs="..." просто добавляется строчка "..." с нужным путём и посылается сигнал mountd демону. Поттеринг бы написал свой mountd, чтобы по dbus оповещался, а тут просто, грубо говоря, встроен небольшой набор shell-скриптов для удобства для интеграции с *уже* имеющимися демонами. >А как оно с шифрованием ? Solaris умеет. Я видел выступление на какой-то конференции мужика который его туда и впиливал и он объяснял устройство. Я, как человек очень заинтересованный темой криптографии -- одобряю всё что они там наделали. Грамотно. https://www.youtube.com/watch?v=frnLiXclAMo >мне если делать такие тома то часто нужны временные шифрованные диски. Но вот в OpenZFS, а это всё, что вне Solaris, шифрование не впилили. Поэтому я его на практике не трогал. В итоге я делаю шифрованное блочное устройство (LUKS, GELI) и поверх него уже ZFS. Родная поддержка шифрования в ZFS лучше тем, что можно делать zfs scrub/resilver/send/recv (проверять целостность, работать с массивами, бэкапить и восстанавливать) без загрузки ключей шифрования. Если бэкап отправляется в небезопасное (с точки зрения конфиденциальности место), то zfs send от зашифрованного ZFS означает отправку зашифрованных данных и не потребуется какой-нибудь | gpg -e > zfs.gpg. Автоматом шифруются не только данные/метаданные, но и L2ARC кэши и выделенные диски для ZIL-а. Всё это можно сделать и руками поверх LUKS, но просто более сложное управление и отслеживание всего этого. Мол явно руками придётся прописать сначала подключение зашифрованных разделом, а уж потом zpool import. Судя по слайдам презентации, включение шифрования выглядит так: # zpool create -o encryption= -o keysource= # zfs key -l # load key into zfs for use # zfs key -u # unload key from the system # zfs key -c # change user's key собственно аналогично geli init, geli attach, geli detach (ну и аналогичным командам LUKS). Причём, мне как любителю парольных фраз очень нравится что они из коробки дают возможность их использовать, с PBKDF2 (не айс, но хотя бы так) усилением. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** Igor Savlook <i...@alzari.pw> [2017-06-25 03:08]: >Вроде как UPS может помочь с этой проблемой. На сколько-то минут. Кроме того, внезапный отказ может произойти в компьютере (мать, контроллер, итд). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 00:21]: >У вас прям по ZFS сплошные плюсы. Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы консистентность данных была в порядке, то при записи вы обязаны сделать атомарную запись всех stripe-ов на все диски. А сделать это атомарно на три (или более) аппаратных диска просто невозможно. Внезапное выключение питания запросто приведёт к тому что на каком-то диске что-то недозаписано. И встаёт проблема: кому доверять и как понять на ком недочёт. Решают аппаратные контроллеры её за счёт использования памяти, подпитываемой батарейкой (или SSD в контроллере), где хранится информация о записанных данных. При восстановлении питания, он тогда сможет понять что надо дозаписать. Но это хорошие дорогие контроллеры. Программно так не сделать и при внезапном выключении питания вы сильно рискуете реально потерять данные в stripe массива. С RAIDZ всё что увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей или нет. При пропаже питания вы безусловно рискуете потерять то что не смогло быть чисто физически записано на диск, но никакого нарушения целостности. То есть фича дорогих аппаратных контроллеров с батарейкой или SSD на боту -- бесплатно в софте. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 01:36]: >Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал, >посмотрел e4defrag-ом, меньше двух процентов. На моём ноутбуке сейчас :-): # zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP HEALTH secure 1008M 149M 859M -68%14% 1.00x ONLINE stcvol 15.9G 1.83G 14.0G -42%11% 1.00x ONLINE zroot 89G 32.3G 56.7G -44%36% 1.00x ONLINE >Так всё-таки RAM или дисковое пространство свободное больше требуется? И то и другое :-). Если высокая фрагментация (мало свободного места), то вы всё-равно упрётесь в лавинообразный рост IO на диск и память тут не поможет. ZFS всегда пишет данные в самое большое свободное место на диске (самую большу "дырку"). Вообще штатно считается что в большинстве случаев фрагментация не является проблемой на практике в большинстве режимов использования/нагрузки. Собственно лично я с фрагментацией сталкивался только на дисках куда сбрасываю бэкапы, где я делал это впритык, до последнего гигабайта. >> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде >> resilvering-а, то бишь rebuild-а на диски, при котором на них будет >> дефрагментированный образ создан. >Условно: mv всего на другой раздел? Да, можно и так. Суть одна. Заставить прочитать и записать в другое место. Чтение пускай не очень быстрое (из-за фрагментированного файла), но запись уже более быстрая (менее разряженно). >А нет a-la e4defrag? Нету ни этого, ни xfs_fsr. Только вот хаки. Которые метаинформацию никак не трогают. Повторюсь: проблема фрагментации зависит от режимов нагрузки. Но достаточно, в большинстве случаев, просто иметь место про запас и не париться. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 00:54]: >Вы хотите сказать, что она жрёт 20% места под метаданные?! >Или что она просто начинает сильно фрагментироваться, при заполнении? Из-за её copy-on-write природы она начинает сильно фрагментироваться, верно. Любое изменение данных это создание полной копии и блока данных и сопутствующей метаинформации. Само собой перед записью они агрегируются, но всё-равно при записи большого файла на диск он никогда не будет размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы -- то есть на диске идут сколько-то блоков данных файла, потом всякая метаинформация, снова блоки, потом метаинформация. Причём каждый набор метаинформации создаваемый в последующих 1-5 секунд делает неактуальным предыдущую. То есть она потенциально становится свободным местом. Например *X*FS реально абсолютно последовательно может разместить файл на диске, а ZFS нет -- поэтому и нужно много памяти под кэш чтобы сгладить всё это, не создавая огромный IO на диск. Но вот зато при неправильной конфигурации RAIDZ, в которой выбрать определённое количество дисков и определённый размер блока (recordsize), то можно, фактически, просто так потерять 50% места буквально в пустую. Вот тут есть тема про это: https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz RAIDZ сделан так, что добавляет чётность, но кол-во получившихся блоков для данных+parity должны быть кратны чему-то там и поэтому там будет создан блок чисто для padding-а, для выравнивания некоего, не несущего полезных данных. Статья эта подчёркивает что в RAIDZ на parity всё же будет больше затрачено места чем в аналогичных уровнях RAID, как правило. >Во втором случае, ведь должна быть онлайн дефрагментация... Вот это можно сказать и недостаток. Её нет. Есть хаки в виде resilvering-а, то бишь rebuild-а на диски, при котором на них будет дефрагментированный образ создан. Можно сделать полный zfs send и восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не всегда допустимо и возможно. Есть хаки в виде просто копирования файла: cp file file.tmp && mv file.tmp file, чтобы сделать его дефрагментированным, если, например, он был медленно записан (то бишь, из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они говорят что создание online дефрагментации это жутко нетривиальная вещь, требующая чуть ли не переписывания всего кода, ибо везде всё одна крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так, чтобы гарантировать "железную" надёжность и поэтому не будут делать. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: ZFS
*** artiom <artio...@yandex.ru> [2017-06-25 00:21]: >Там и сжатие есть? Я вот тут упомянул: https://lists.debian.org/debian-russian/2017/06/msg00618.html что у меня на практике 60 GB MongoDB превратилась в 20 GB занятого места и соответственно в памяти кэш ФС тоже в три раза меньше жрёт. Это если LZ4 сжатие, которое очень CPU дешёвое. По-умолчанию оно отключено, если что. >У вас прям по ZFS сплошные плюсы. >Вы, случаем, не её разработчик, так нахваливаете? :-) >Минусы-то, недоработки и баги у неё какие есть? Я очень консервативен и моё внимание сложно привлечь новинкой, чаще я скажу "очередное хипсторское поделие" (честно говоря я с Debian ушёл из-за его systemd по-умолчанию, хотя использовал 7 лет). Но вот ZFS, действительно удивительно, оказалась для меня неким Святым Граалем в мире ФС/RAID/LVM/etc. Нет, я не её разработчик, денег за хорошие слова в её сторону не получаю :-). Просто в искреннем восторге от неё и за все годы знакомства с ней и использования жалел только о том, что раньше и активнее не начал её использовать. Минус наверное могу сказать только тот, что не всегда понятно как лучше поднастроить её для хорошей производительности например под СУБД. RAIDZ можно сконфигурировать так, что там будут очень большие потери места впустую. Все эти шаманства с разными размерами блоков... без этого никуда, ведь ZFS не может же знать какие прикладные задачи поверх неё вы применяете. Хотя наверное это относится к любой ФС/mdadm/LVM -- tuning касается всего, но на ZFS это может отражаться в десятках процентах или даже разов. В общем опыт и понимание нужны. Дорогая она. Например нужно иметь пустого места достаточно, чтобы фрагментация не убила производительность в ноль. То есть, вместо 10 TB диска вы получите 8 чтобы всё было более менее (хотя если речь про хранение последовательно записанных файлов только для чтения, типа хранилки фильмов, музыки, архивов с бэкапами, то можно чуть ли не битком набивать). На 32-бит системах она вроде как официально даже не поддерживается. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
