All streams
Search
Write a publication
Pull to refresh
16
73
Send message

И постгря, о которой шла речь, отношения к синхронным записям не имеет?)

уже замечал выше, но повторюсь: zfs нужно уметь готовить.
>> попробавали перевести на нее раздел
slog то хоть вынесли на отдельный диск? подобное решение без отдельного slog приведет к тому, что все данные будут записываться дважды
второй кейс странный, ни разу не встречал подобного запроса.

многие слишком привыкли к грабу, поэтому я его оставил. к тому же граб - достаточно гибкая штука. кому-то нравится бут меню с условными windows, memtest86.efi, etc без необходимости спамить delete, кто-то слишком любит minegrub, поэтому пусть будет)

в моем же случае загрузка происходит через efistub ядро, initramfs лежит вместе с ядром в ESP. "Наверное, вы еще не готовы к этому, но вашим детям понравится" (с)

подшаманенный загрузчик юзер вдски вполне вероятно заметит. а сдампленную память нет =)

zfs нужно уметь готовить. если просто создать zfs на одном устройстве, то чуда ждать не стоит: как минимум все данные будут записываться дважды. я рассказывал как в zfs устроены чтение и запись вот здесь - https://habr.com/ru/companies/selectel/articles/921770/

ну и ради интереса посмотрел сейчас arc_summary на своем рабоче-игровом десктопе: под arc выделено 32гб и за 26 дней аптайма 99.6% чтения происходило из ARC, расположенного в озу. стоит ли говорить, что это намного быстрее любого nvme?)

единственное, что не понравилось в zfs - невозможность решейпинга (mdadm, например, умеет преобразовать raid1 в raid5 прямо на месте). при этом добавить в raidzX еще один диск, расширив пул, можно начиная с 2.3 - https://github.com/openzfs/zfs/releases/tag/zfs-2.3.0
"вырастить" zpool, заменив по очереди все диски на диски бОльшего объема тоже можно.

по сути остается только заранее продумать свою хранилку, чтобы избежать необходимости решейпинга. небольшая плата за возможности и удобство, которые дает zfs. а совать в хранилку разные диски разного объема - это скорее про ceph

если подушнить, то есть возможность как минимум сдампить память процесса qemu, где будет ключ шифрования. однако заниматься этим маловероятно кто-то будет: трудоемко и сложно, а ради чего? к слову защита от подобных манипуляций тоже есть - AMD SEV

пакет zfs-initramfs именно это и делает)

можно, но:
1. граб имеет крайне ограниченную поддержку zfs, создавать 2ой пул с ограниченным набором фич для /boot как будто избыточно
2. в случае с efistub /boot и так можно хранить в основном zpool-е, но само ядро и initramfs должны быть в ESP, которую уже никак не засунуть в zfs

привычка шифровать удаленные сервера целиком у меня появилась еще с вдсок, после того как я начал работать в облачном провайдере и обнаружил, что админ гипера может слишком много. а еще приходилось обрабатывать запросы от силовиков на вытаскивание данных из вдсок

  1. zstd медленнее lz4, а профита практически никакого не заметил

  2. -О и -о - абсолютно разные ключи. -о используется для задания параметров zpool, а -О для параметров корневого датасета (которые будут унаследованы дочерними датасетами)

Уже добавлено недельку назад) Скоро публикация

Окак. А смарт что говорит? Сколько было записано в диски? Просто даже интелевые серверные диски (nand, не оптаны) у меня показывали признаки деградации после 700 впитанных тб. Кроме того для некоторых юзкейсов использование sata ssd для l2arc противопоказано: в последовательном чтении у 1ого sata ssd вполне вероятно выиграет radizX с несколькими hdd. Себе для l2arc я выбрал NVMe оемник - Hynix pc801 (он же Hynix P41 Platinum, он же Solidigm P44 Pro). Такое решение быстрее raidzX на жестких дисках как по пропускной способности, так и по IOPS-икам. Глянул смарт: за 2к часов впитал в себя всего 1.8тб, видимо проживет еще долго)

Обычные пользовательские SSD обычно имеют SLC кэш 10-20% от обоего объема. Пока запись идёт в него - диск показывает хорошие показатели производительности. Как только SLC кэш заканчивается и начинается TLC или ещё хуже QLC - иопсы просто испаряются. Если запись в диск происходит регулярно, то SLC кэш просто забивается. Серверные ссдшки же демонстрируют на всем объеме одинаковые показатели производительности

а windows у меня далеко не любимая ос)

ну и в теории через wsl сделать это можно...

окак. так и не удалось на живом примере опробовать их. звучит слишком хорошо, чтобы быть правдой, поэтому видимо в список покупок добавляются два оптана)

по существу:
1. двойного кэширования нет (за исключением mmap()), т.к. в слое vfs со стороны zfs оно намеренно не реализовано, соусы:
реализация слоя vfs - https://deepwiki.com/openzfs/zfs/3.1-vfs-layer-and-posix-interface
годная лекция о том, как в zfs устроены чтение и запись - https://openzfs.org/wiki/Documentation/Read_Write_Lecture
и вот тут прямым текстом сказано, что arc заменяет дефолтный page cache с его lru - https://openzfs.org/wiki/System_Administration
2. openzfs использует лицензию cddl, в ядро линукса по этой причине не войдет, но это не мешает ее использовать. может apt install zfs-initramfs или даже сборка модуля ядра ручками все же стоит получения гибкого и эффективного инструмента хранения?
3. очень странный тейк. обычно ос выбирается исходя из задач, которые собираешься решать на машине, а не какую фс хочешь использовать. но для меня zfs всегда был просто крутым инструментом и я не вижу ничего плохого в том, чтобы подружить его с любимой ос

пупупу. возможно и правда стоило указать это явно. мне этот момент казался "настолько очевидным, что нет смысла описывать", цитируя великих

UPD: к тому же это уже было сказано в предыдущей публикации)

1

Information

Rating
95-th
Registered
Activity

Specialization

System Administration, DevOps
Middle
From 250,000 ₽
Git
Python
Linux
English
Docker
MySQL
Nginx