Вот. Поэтому raidz+1 и никаких спар

Причем если диск не вылетел в первый год, то вероятность вылета в ближайшие 5-10 лет резко падает, - это одна из причин, почему не стоит держать в spare непроверенные новые диски.

так наоборот же

Это обычно про сегейт)

Диски всегда в тесте. Выход на один диск безопаснее

Ага, и бегай меняй в кратчайший срок, не смешно, spare обязателен если данные важны

И там и там менять надо. Только в ркйд д, ты ещё можешь потерять данные во время ребилда на один диск выше

дока выше, там всё описано

Я понимаю как работает рейд д Дай мне конфигурацию где это решение надежнее, ну или хотя бы не хуже

Ага, и бегай меняй в кратчайший срок, не смешно, spare обязателен если данные важны

Спар к рейдд???)))

https://prefetch.net/blog/2007/02/09/using-raidz2-and-hot-spares-on-older-sun-storage-arrays/

Всем доброго времени суток. Ну подскажите такой момент, надо ли в zfs выделять отдельные ssd диски под метаданные? Хотим пул на 20 штук 8тб sas 7200 дисков с fault tolerance=3

Всем доброго времени суток. Ну подскажите такой момент, надо ли в zfs выделять отдельные ssd диски под метаданные? Хотим пул на 20 штук 8тб sas 7200 дисков с fault tolerance=3

Диски идентичные, хотим все в один пул, чтобы копия одного блока данных была на 3х физических дисках. В основном будет запись (много камер наблюдения)

смотря как будете утилизировать иопсы, но в целом лучше да, взять ссд под ZIL и под arc2, хватит одного ссд, если что и zil и arc2 легко отключаются и подключаются

Смысл l2arc если диски идентичные, только озу и диски изводить, т.к. Чтение с обычного vdev будет идентичным. Тоже самое и с slog, zil есть в пуле всегда, его выделять только для небольшого уменьшения фрагментации со временем можно (но с 2.1 емнип это тоже пофиксили и теперь выделяется приоритетный metaslab под него)

ну я вынес сунк на зил (рейдз3) и получил приблизительно х3-х4 по иопсам

Вот как раз для видео, думаю не так опасно отключить синк

Ценность записей с камер наблюдения в данном кейсе примерно так же важна, как и бд

arc2 будет бесполезен, а zil+sync=latency дадут эффект

чейто? если иопсы будут в полку - вынос сунка на ссд разгрузит блочники

До того момента, когда ссд заполнится. А потом - почти нескончаемый клинч всего и вся

нет?

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

в 2.1 уже есть патч чтобы такого не было

для обновления же ребут не нужен? только фичи апгрейднуть?

модуль надо новый загрузить

ядра?

Например, ситуация. Пропускная способность дисков - 10 единиц. Записать требуется 8 единиц в момент времени. Даже если ты решишь отложить запись например на эквивалент 20 единиц, при заполнении ты только догонять будешь это все добро секунд 10 при котором все просто встанет.

Например, ситуация. Пропускная способность дисков - 10 единиц. Записать требуется 8 единиц в момент времени. Даже если ты решишь отложить запись например на эквивалент 20 единиц, при заполнении ты только догонять будешь это все добро секунд 10 при котором все просто встанет.

Вот чего бы не поставить ext4 и не забыть про проблему с иопсами?

утилизация пространства выше чем на lvm, на моих объемах ощутимо

у меня убунта с dkms, должно проглотить без ребута

ну пулы всё равно экспортить импортить при этом

ну секундный даунтайм еще терпимо

ну секундный даунтайм еще терпимо

это если скрипт написать чтобы экспорт - анлоад модуля - лоад модуля - импорт быстро сделать