Обратная связь на Использовании ZFS и FreeBSD

Я использовал FreeBSD+ZFS с устройством хранения данных на более чем 2 ТБ в течение прошлых двух лет без любых проблем. Однако я предлагаю, чтобы Вы использовали FreeBSD 8 (amd64) та поддержка версия 13 ZFS.

одна вещь, о которой Вы могли основывать свое решение: в каких функциях Вы нуждаетесь и какой находятся там в freebsd реализации zfs?

http://wiki.freebsd.org/ZFS указывает на нерешенные вопросы вполне прилично.

(например, во время записи этого fbsd не поддерживает iscsi на zfs, как это кажется. так как Вы хотите использовать свое поле в качестве устройства хранения данных / резервное копирование, и возможно у Вас есть яблоко, суетящееся... им нравится iscsi, специально для машины времени),

Я использовал FreeBSD 8.0 и впоследствии снимок 2010 года с 8.0 стабильными февралями для экспериментирования с ZFS в течение нескольких месяцев. Система имеет несколько независимых пулов RAIDZ1 с 4 дисками. В первых вещах, казалось, пошел более или менее отлично, хотя я столкнулся с некоторыми все больше тревожащими проблемами, который заставляет меня думать, что при некоторых конкретных обстоятельствах и конфигурациях может быть мудро избежать этой установки. Моя первая проблема не обязательно с устойчивостью / функциональность не FreeBSD / ZFS в целом самостоятельно, а скорее с надежностью и функциональностью определенных драйверов устройств и несколько дисков в соответствии с FreeBSD. Я нашел, что значение по умолчанию ata/ide драйвер не поддерживало контроллер, который я использую, но siis кремниевый драйвер устройства хранения данных изображения имел необходимый множитель порта поддержка SATA, чтобы заставить диски работать с FreeBSD 8. Однако после более близкого контроля, что код драйвера не является действительно производством, готовым, по моему скромному мнению - это корректно не обрабатывало первую связанную с диском исправимую ошибку / тайм-аут / условие повторной попытки, которое заставило диск в массиве делать что-то как задержка, отвечающая в течение нескольких дюжин секунд. Я не знаю точно, что произошло, но потребовалось приблизительно минута для массива к тайм-ауту, сбросу, и восстановите операцию, за это время каждый диск в массиве был 'потерян' от операционного состояния и привел к неисправимому отказу данных на более высоком уровне файловой системы. AFAICT даже специалист по обслуживанию драйвера SIIS говорит, что тайм-аут драйвера / обработка сброса еще не действительно полностью завершается / устойчивый / оптимизированный. Достаточно ярмарка, но точка, неважно, насколько хороший ОС или ZFS, если у Вас есть ненадежный несколько диск или контроллер или драйвер, это может, конечно, разрушить полные операции достаточно для порождения фатальных ошибок и потери данных несмотря на ZFS. Также УМНЫЕ запросы диагностики, кажется, не работают с этим конкретным драйвером контроллера. Что касается того, что вызвало ошибку.. облупленная Seagate управляет / встроенное микропрограммное обеспечение? Я не знаю, но наличие одной причины ошибки диска, целый массив, чтобы 'перестать работать' несмотря на RAIDZ побеждает смысл надежности RAIDZ. Поведение, последующее за проблемой со шпулькой scrup/, буферизует состояние и. al. был также немного подозрителен, и не действительно ясно, работала ли та диагностика / процесс восстановления правильно на уровне ZFS/ZPOOL; конечно, я получил некоторые смешанные сообщения об ошибочных состояниях и ошибочной очистке и. al. Ошибочный вид признаков исчезнувших после перезагрузки несмотря на отсутствие явной шпульки очищает команду; возможно, это предназначается, но раз так это не было предложено выводом состояния шпульки.

Потенциально более серьезно что-то, кажется, ТИХО пошло не так, как надо во время операции после нескольких дней времени работы, где значительные части массива, содержащего несколько файловых систем (ZFS) просто, "исчезли" от того, чтобы быть перечисленным в (ls), и от нормального доступа ввода-вывода. IIRC df-h, ls, и т.д. не сообщил о файловых системах, как раз когда существующий, тогда как список шпульки / состояние шпульки продолжало указывать на ожидаемую сумму использованного устройства хранения данных в пуле, но это не составлялось никакими перечисленными смонтированными или размонтированными файловыми системами./var/log/messages не содержал ошибочного сообщения ситуации, и операции продолжались полностью обычно afaict до той проблемы. буферизуйте список / состояние шпульки не указало на проблемы с пулом. zfs размонтировал-a, отказавший с занятым признаком ни по какой очевидной причине, касающейся интерактивного использования в течение нескольких минут, прежде чем последняя из смонтированных zfs файловых систем размонтировалась бы. При перезагрузке и перепроверке/var/log/messages, состояние шпульки, список шпульки был весьма формирующим из любой проблемы. Ранее недостающие файловые системы действительно на самом деле повторно монтировали, когда их попросили сделать так вручную и, казалось, первоначально имели корректное содержание, но приблизительно после одной минуты монтирования различных zfs систем в пуле было отмечено, что некоторые снова неожиданно исчезли. Возможно, что я сделал что-то не так с определением zfs файловых систем и так или иначе вызвал проблему, но в данный момент я нахожу это необъяснимым, что рабочая система, делающая ввод-вывод к различным zfs каталогам, может внезапно потерять представление всех файловых систем, которые работали просто великолепно несколько минут/часы/дни назад без прошедших команд системного администратора для изменения основной zpool/zfs конфигурации.

Предоставленный я выполняю февраль '10 устойчивых снимков, которые НЕ рекомендуются для производственного использования, но с другой стороны несколько относительно примечательных мер к известным проблемам ZFS/storage посвятили себя стабильному ответвлению начиная с 8,0 выпусков, таким образом, рабочий запас 8.0 мог бы быть неудовлетворительным с точки зрения надежности / функции из-за тех проблем для некоторых людей.

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

OpenSolaris является остановкой прямо сейчас так или иначе, по моему скромному мнению, даже если Вы хотели выполнить его - afaict существуют серьезные известные проблемы с zfs дедупликацией, которая в значительной степени представляет его неприменимый, и это и другие проблемы, кажется, привели к рекомендации ожидать еще нескольких версий патча для выхода прежде, чем доверять OpenSolaris+ZFS особенно с dedup системой. B135/B136, кажется, просто отсутствуют выпущенный без объяснения, наряду с 2 010,03 главными версиями ОС. Некоторые говорят, что Oracle просто трудна загнутый об уменьшении расписания, но что ожидаемые коды будут запоздало выпущены в конечном счете, тогда как другие задаются вопросом, будем ли мы когда-либо видеть, что полный набор ожидаемых функций в разработке Sun выпущен как будущие версии с открытым исходным кодом Oracle, учитывая переход во владении / лидерство / управление.

По моему скромному мнению, я придерживался бы выполнения зеркал только, и только очень хорошо исследуемым / стабильные драйверы контроллера запоминающих устройств и модели несколько диска для оптимальной надежности ZFS под FreeBSD 8, и я буду, вероятно, ожидать 8,1, несмотря на это.