Комментарии 34
А через время что делать с фрагментацией, которой там только теоретически не бывает?
И, конечно, главный вопрос: если массив развалится, каким софтом в не удастся разобраться, чтобы хотя бы большую часть информации восстановить?
Сам очень люблю zfs, но есть моменты, которые за столько лет так и остались неотвеченными.
Я знаю что FRAG в выводе zpool list — это фрагментация свободного места в пуле. А не, как принято считать, фрагментация файлов.
zfs довольно устойчива к разваливанию. И судя по тому как она хранит данные, то нет особо смысла что-то там восстанавливать при отвалившихся n дисках.
Картинка про то как хранит тут:
github.com/zfsonlinux/zfs/wiki/dRAID-HOWTO
Лично я жду draid в production. Время ребилда будет сильно уменьшено что несомненный плюс.
Я считаю что описанный выше случай с неконсистентностью просто не возможен в zfs by design. В связи с применением «сквозного контроля целостности данных».
Если заполнение диска большое, то фрагментация будет портить жизнь. Кеширования спасают, но не всегда: время поиска у физических дисков все равно никуда не девается.
«Keep pool capacity below 80% for best performance»
Так это для всех ФС справедливо. Вопрос в другом: чем лучше и умнее ФС (а zfs сразу и ФС, и ещё много чего в одном флаконе), тем сложнее восстановить данные, если она сама не справится.
И не вариант сказать "пока не умеет, но лет через дцать научится" — в случае zfs лет прошло много.
Поэтому и говорю: ее использовать прикольно, но нужно заранее подумать над двумя вещами, а именно производительностью (потому что её правильно готовить умеют единицы), и шансом на восстановление.
И то, что она обычно держится и не разваливается, второго вопроса не снимает. Вот, выше по комментариям люди говорят, что им по бюджету не хватало средств купить дисков для лучшего вариант хранения — может и на полноценное резервное копирование не хватить, а надеяться только на основную хранилку все равно не очень верно.
Но вообще, да, zfs неплоха. Жаль, что в Линукс ее привезли не так давно.
По второму случаю и проблеме ничего не понятно. Разве на уровне FC не было настроено зонирование? И сервер с основной площадки просто по идее не должен видеть порты массива на второй площадке, хоть таргеты они, хоть инициаторы? Да и в принципе, под репликацию обычно рекомендуются отдельно выделенные под это порты и отдельные зоны для этих портов между массивами. Без пересечений с вводом\выводом от хостов к массивам.
Если есть понимание, как у вас сервер увидел порты массива на удаленной площадке, то поясните пожалуйста.
То скорее всего заблокировался ввод вывод для определенных lun'ов — а видимо один из них и использовался злосчастным linux'ом.
Вообщем root cause указанных в статье вызывает много вопросов =)
Про тергетов и инициаторов тоже надо пояснить, что это не корневая причина, а лишь наша версия корневой причины. В чем конкретно заключается корневая причина до конца не ясно.
Похоже на байки подвыпивших СЦ Инженеров в Пив-баре
Кака же интересная у Вас работа… как же я хочу там с вами работать) но я только windows сис админ((
И про дисковые пулы непонятно. В них из mdisk собирается ещё бОльший рейд?
Пара историй про RAID’ерский беспредел