а чего тогда в линукс дистрах от дискарда отказываются и рекомендуют трим ?

можно ссылку?

так линейноая запись, не ?

в общем у вас метод бенча странный. dd с 64МБ блоком != последовательная запись от приложения, плюс вы вообще io queue depth тут не учитываете

если хотите адекватно бенчить - fio

https://wiki.archlinux.org/index.php/Solid_state_drive

Note: Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [5], Debian does not recommend using continuous TRIM [6] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [7]

если хотите адекватно бенчить - fio

я fio тоже большими блоками бенчил

в общем понял. zfs всеравно будет писать меньшими блоками и не всегда последовательно. в таком разе мой днищессд утилизируется полностью

Note: Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [5], Debian does not recommend using continuous TRIM [6] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [7]

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

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

в общем понял. zfs всеравно будет писать меньшими блоками и не всегда последовательно. в таком разе мой днищессд утилизируется полностью

наоборот только обычно, в отличии от других ФС zfs будет по дефолту писать блоков 128КБ , а не 4 или 8 как большинство других

ммм, тада непонятно. скорость должна быть в 2 с небольшим раза выше.

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

ну если терроризировать тримом - да, это плохо

ммм, тада непонятно. скорость должна быть в 2 с небольшим раза выше.

не должна, тесты диска блоком 64МБ бессмысленны

но и 100% вы с диска не выжмете, это да

а как я могу трим делать ? чет не соображу. т.к. обычно трим к точке монтирования привязан

fstrim -v -a ничего не делает

а как я могу трим делать ? чет не соображу. т.к. обычно трим к точке монтирования привязан

а что вы хотите сделать?

ну мне рекомендуют трим включить )

мб zfs сам посылает команды трим ?

ну мне рекомендуют трим включить )

где вам его рекомендуют включить?

я вам рекомендовал партицию меньше сделать и место оставить для ссд

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

вот

ну это не "включить трим"

)

ATA Secure Erase можно сделать для ssd

это фактически будет discard для неё

ок

в общем, партиции выравнивать надобно для slog

скорость увеличивается

вот

сделать дискард - это очистить весь диск вам предложили)

blkdiscard /dev/sda

чет хз как выгнать ssd из состояния frozen

ребуты и выключения не помогают

всем доброго дня. потестировал автозамену диска из hotspare. но потом остаётся такая картина

выгнать лишнюю spare не получается

а производительность записи отчего-то упала в 2 раза

pool: rpool state: ONLINE

выгнать лишнюю spare не получается

remove не даёт сделать?

так может он ресилверинг делает?

zpool remove rpool ata-TOSHIBA_MG04ACA400E_99AOK2JNFJKA cannot remove ata-TOSHIBA_MG04ACA400E_99AOK2JNFJKA: root pool can not have removed devices, because GRUB does not understand them

так может он ресилверинг делает?

не, не делает

scan: resilvered 54.6G in 0 days 00:04:33 with 0 errors on Thu Jan 16 22:48:45 2020

а как вообще менеджить вылетевшие диски ?

нет удобной команды для просмотра ?

zpool remove rpool ata-TOSHIBA_MG04ACA400E_99AOK2JNFJKA cannot remove ata-TOSHIBA_MG04ACA400E_99AOK2JNFJKA: root pool can not have removed devices, because GRUB does not understand them

так ты пытаешься такой командой удалить уже диск в составе пула

хм. для не in use spare работает нормально

zpool detach делал?

не понимаю почему для этого mirror 3 диска юзается, и что еще хуже - стала тормозить запись.

а как выглядел пул до замены?

zpool detach делал?

помогло я руководствовался https://docs.oracle.com/cd/E53394_01/html/E54801/gpegp.html

вот так выглядело

почему spare не автодетачится, когда она не нужна ?

Друзья, #вопрос : есть кластер из 3 нод. На двух ZFS (raid1) на третей LVM(soft raid1). насколько хорошо они будут дружить в LINStor? Стоит ли заморачиваться и заново разметить диски? Один из серваков стоит под бекапы, второй для elasticsearch третий как продакшн web server на nginx. Еластик на LVM остальные на ZFS. Думал и прод на LVM перевести из-за производительности (имеется 2NVMe диска на проде).

Друзья, #вопрос : есть кластер из 3 нод. На двух ZFS (raid1) на третей LVM(soft raid1). насколько хорошо они будут дружить в LINStor? Стоит ли заморачиваться и заново разметить диски? Один из серваков стоит под бекапы, второй для elasticsearch третий как продакшн web server на nginx. Еластик на LVM остальные на ZFS. Думал и прод на LVM перевести из-за производительности (имеется 2NVMe диска на проде).

2 nvme на каждом сервере ?

На одном 2ссд по 250гб на втором 2nvme по 500гб, третий обычные свалки по 2тб 7200rpm

линстор не сможет синхронно реплицироваться при таком зоопарке

мне посути нужно только между двумя нодами (на ссд и nvme дисках) держать реплику. Третий просто ежедневно на кроне создает потихоничку бекапчик в час ночи, и хранит у себя на всякий случай.

Имею сервер: # camcontrol devlist <HGST HUH721010ALE600 LHGNT384> at scbus0 target 0 lun 0 (ada0,pass0) <HGST HUH721010ALE600 LHGNT384> at scbus1 target 0 lun 0 (ada1,pass1) <HGST HUH721010ALE600 LHGNT384> at scbus2 target 0 lun 0 (ada2,pass2) <HGST HUH721010ALE600 LHGNT384> at scbus3 target 0 lun 0 (ada3,pass3) <AHCI SGPIO Enclosure 2.00 0001> at scbus6 target 0 lun 0 (ses0,pass4) # zpool status zroot pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/system-ada0 ONLINE 0 0 0 gpt/system-ada1 ONLINE 0 0 0 gpt/system-ada2 ONLINE 0 0 0 gpt/system-ada3 ONLINE 0 0 0 errors: No known data errorsКак склонировать пул zroot на идентичное железо?

на ум приходит только: 1) риск режим целевой системы 2) копирование по ssh через dd раздела gpt/system-ada0 на первый диск нового сервера

далее импорт пула zroot, клонирование нового раздела на остальные три диска и добавление их в пул zroot

дык zfs send/recieve?

https://128bit.io/2010/07/23/fun-with-zfs-send-and-receive/

я так 4 тера скопировал не так давно

Делаешь снапшот, да сендишь его куда надо

Куда копировать? на целевой системы диски НЕ размечены!

Куда копировать? на целевой системы диски НЕ размечены!

У тебя zfs как рутовая фс?

Да.

На принимающей стороне rescue или live cd поднять с zfs, создать новый пул, снапшотами zfs send recv

Dd всех дисков конечно тоже сработает:)

На принимающей стороне rescue или live cd поднять с zfs, создать новый пул, снапшотами zfs send recv

хотелось бы другого механизма

Dd всех дисков конечно тоже сработает:)

диски по 10ТБ

Но zfs recv будет лучше тем, что данные заново будут разложены с меньшей фрагментацией

хотелось бы другого механизма

Какой?

1) Создание скелета разделов (возможно по SSH удасться) 2) клонирование только пула ZFS (без данных)

1) Создание скелета разделов (возможно по SSH удасться) 2) клонирование только пула ZFS (без данных)

не понял, просто пустой пул создаёшь, корневые датасеты, а в них льёшь рекурсивно уже снапшоты

1) Создание скелета разделов (возможно по SSH удасться) 2) клонирование только пула ZFS (без данных)

так это будет не копия пула, а копия его структуры. Это полностью меняет первоначальный вопрос

не понял, просто пустой пул создаёшь, корневые датасеты, а в них льёшь рекурсивно уже снапшоты

это очень долго ручками

вопрос звучал "Как склонировать пул zroot на идентичное железо?"