да, вопрос именно в этом. как это сделать?

:)

либо скриптик написать, либо поискать готовые

нужен treemap для dataset-ов (не файлов)

тогда zfs list

в названиях присутствуют паренты, от которых можно строить деревья

сейчас под рукой консоли с зфс нету

и не надо

мне нужно просто сконверить zfs list -p в treemap

не встречал таких задач :)

буду рад если кто-нибудь конструктивное кинет.

довольно наглядно получится, кстати. поищу ка тоже.

с физикой не поспорить, увы. если надо какие-то плюшки, типа ссд кеша, вроде бы @maverickdeb говорил, что у лвм появился ссд кеш :)

Ну что то такое было в инете. Но вот насколько оно работоспособность остаеться вопрос.

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

почему нельзя сделать проверку транзакций более устойчивую у сбоям памяти? Или требовать повторной транзакции или отбрасывать с записью в соответствующий лог?

почему нельзя сделать проверку транзакций более устойчивую у сбоям памяти? Или требовать повторной транзакции или отбрасывать с записью в соответствующий лог?

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

проще оперативку нормальную поставить, и забыть об этом :D

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

В FC работает принцип FIFO на портах с ограниченными размерами буферов

Кстати, кто-нибудь DTrace баловался тут?

Кстати, кто-нибудь DTrace баловался тут?

Пользую на фряхе. Там же теперь есть еще dwatch

почему нельзя сделать проверку транзакций более устойчивую у сбоям памяти? Или требовать повторной транзакции или отбрасывать с записью в соответствующий лог?

Да потому что там и так все устойчиво дальше некуда, а те нереальные миллионые доли процента вероятности сбоя в вашем случае наступят не раньше, чем Вы к Альфе Центавра сгоняете)

почему нельзя сделать проверку транзакций более устойчивую у сбоям памяти? Или требовать повторной транзакции или отбрасывать с записью в соответствующий лог?

очевидно, потому что эту задачу решает ECC более дешевым способом

стоимость ECC модулей не всегда приемлима

завтра вся память ECC станет, в DDR5 обязательное условие. А они делали для серверов файловую систему, для своих крутых железок на соляресе

никто не просил использовать ZFS где то еще, но так случилось, что они открыли ее исходники на какое то время

стоимость ECC модулей не всегда приемлима

Это должно закладываться в бизнесплан

попытка визуализировать zfs-list

А в тестовом виде не проще?

какой нибудь вывод с черточками, рисующими дерево, умело отсортированное

хотя.. наверное нет..

100 датасетов уже не очень переваривается

попытка визуализировать zfs-list

и как именно вы это сделали? можно скрипт или how-to ?

и как именно вы это сделали? можно скрипт или how-to ?

(echo "name\tvalue" && zfs list -pHr -o name,usedbydataset) > data.tsv

+

а дальше?

https://gist.github.com/mizhka/451c321eec3dd45dae291742d4a08c5c

строка 41 - пропиши путь свой, строка 58 - топовые названия датасетов (у меня в zvol-е оказалось их 6) для цветовой схемы

ок, грязненько

дык за сегодня только накатал ))

надо было путь и массивы вытащить в начало, как переменные

давай

тащи

я пока понял что хотел, может потом руки дойдут

ок, грязненько

главный вопрос - работает?

echo пока заменил на printf

html потом протестю

попытка визуализировать zfs-list

Опа опа

Какая интересная идея

Всем привет.

Message from Ivan deleted. Reason: new user and forwarded (?)

ээх не судьба

вот допустим я диск с кэшем вытащу или сам помрёт. zfs откажется грузиться, то исключение устройства можно будет только с livecd сделать ?

вот допустим я диск с кэшем вытащу или сам помрёт. zfs откажется грузиться, то исключение устройства можно будет только с livecd сделать ?

а откуда информация, что откажется грузиться?

вот допустим я диск с кэшем вытащу или сам помрёт. zfs откажется грузиться, то исключение устройства можно будет только с livecd сделать ?

в zfs можно добавить cache устройство или log устройство

первое - для ускорения чтения данных, второе "в определенном смысле" для ускорения записи данных

ваш вопрос точно про cache устройство? в этом случае авария этого диска не будет иметь последствий

вот допустим я диск с кэшем вытащу или сам помрёт. zfs откажется грузиться, то исключение устройства можно будет только с livecd сделать ?

вообще мне кажется, что и log устройство не требуется для работы пула.. если сломается, то пул все равно должен быть в рабочем состоянии. Щас проверю)

вообще мне кажется, что и log устройство не требуется для работы пула.. если сломается, то пул все равно должен быть в рабочем состоянии. Щас проверю)

Во интересненько

ага. без лога не импортируется в стандартном режиме. Нужен дополнительный ключ -m Импорт пула идет на ранней стадии загрузки

нужно импортировать вручную через zpool import -m имя пула

затем отключить лог устройство, и все сново станет загружаться автоматически. Короче нужен доступ к консоли сервера, если после поломки log устройства сервер был перезагружен! Нужен IP KVM

После этого все загрузилось

т.е. даже при / на zfs не потребуется возни с livecd ?

т.е. даже при / на zfs не потребуется возни с livecd ?

да, я протестировал на виртуалке :) поставил проксмокс в VM на PVE хосте 😉

да, я протестировал на виртуалке :) поставил проксмокс в VM на PVE хосте 😉

спасибо :)

А подскажите, как проверить поддержку TRIM в ZFS ? root@pve2:~# lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 0B 0B 0 ├─sda1 0 0B 0B 0 ├─sda2 0 0B 0B 0 └─sda3 0 0B 0B 0 sdb 0 0B 0B 0 ├─sdb1 0 0B 0B 0 ├─sdb2 0 0B 0B 0 └─sdb3 0 0B 0B 0 sdc 0 0B 0B 0 ├─sdc1 0 0B 0B 0 └─sdc9 0 0B 0B 0 sdd 0 0B 0B 0 ├─sdd1 0 0B 0B 0 └─sdd9 0 0B 0B 0 sde 0 32M 4G 0 sdf 0 32M 4G 0 sdg 0 32M 4G 0 sdh 0 32M 4G 0 sr0 0 0B 0B 0root@pve2:~# zpool status pool: rpool state: ONLINE scan: scrub repaired 0B in 0h0m with 0 errors on Mon Aug 26 01:24:06 2019 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 sda3 ONLINE 0 0 0 sdb3 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 sdc ONLINE 0 0 0 sdd ONLINE 0 0 0 errors: No known data errors

вроде как, если версия OpenZFS > 0.8, трим должен быть.

больше пока не крутил

Чатик растёт

👍

Всем привет.

Нужен совет. Имеется proxmox с 2 дисками sata работающих в зеркале на zfs. Есть два диска ssd. Как посоветуйте максимально убыстрить работу дисков и притом сделать хорошую отказоустойчивось?

SSD одной модели и из одной партии? НЕ забудьте бэкап настроить

Модель одна партии может и разные.

Бэкап это понятно. Кто что в сети советует в плане вывода кэша.

Диски 120g. Можно на них вывести и лиги и кэш и хватит ли места.... Пока знаю что в зеркало надо... Хотя некоторые говорят что плохо кэш выводить на зеркало да и смысла нет...

не будет никакого прироста производительности, полученной от SSD, работающих как кэш дисков

хотя 120ГБ - это обычные дешевые SLC SSD