Я использовал FreeBSD 8.0, а затем снимок 8.0-stable-February 2010, чтобы экспериментировать с ZFS в течение нескольких месяцев. В системе имеется пара независимых 4-х дисковых пулов RAIDZ1. Поначалу казалось, что все идет более-менее идеально, хотя я столкнулся с некоторыми все более тревожными проблемами, которые заставляют меня думать, что в некоторых конкретных обстоятельствах и конфигурациях может быть целесообразно избегать такой настройки. Моя первая проблема не обязательно связана со стабильностью / функциональностью не самих FreeBSD / ZFS, а скорее с надежностью и функциональностью некоторых драйверов устройств и дисководов в FreeBSD. Я обнаружил, что драйвер ata / ide по умолчанию не поддерживает используемый мной контроллер, но у драйвера хранилища образов siis Silicon была необходимая поддержка SATA для умножения портов, чтобы приводы работали с FreeBSD 8. Однако, при более внимательном рассмотрении, код драйвера на самом деле не готов к работе, ИМХО - он не изящно обработал первое связанное с диском мягкое состояние ошибки / тайм-аута / повторной попытки, которое заставило диск в массиве сделать что-то вроде задержки, отвечающей на несколько десятков секунд. Я не знаю точно, что произошло, но массиву потребовалось около минуты для тайм-аута, сброса и восстановления, в течение которого каждый диск в массиве был «потерян» из рабочего состояния и привел к неисправимой ошибке данных на более высоком уровне файловой системы. AFAICT, даже сопровождающий драйвера SIIS, говорит, что таймаут / обработка сброса драйвера еще не полностью завершены / устойчивы / оптимизированы. Справедливо, но суть в том, что независимо от того, насколько хороша ОС или ZFS, если у вас ненадежный дисковод, контроллер или драйвер, он, безусловно, может разрушить все операции в достаточной степени, что приведет к фатальным ошибкам и потере данных, несмотря на ZFS. Также кажется, что запросы диагностики SMART не работают с этим конкретным драйвером контроллера. Что касается того, что вызвало ошибку .. Слезные диски Seagate / прошивки? Я не знаю, но наличие ошибки одного диска приводит к «отказу» всего массива, несмотря на то, что RAIDZ разрушает весь смысл надежности RAIDZ.
Поведение после проблемы с zpool scrup / zpool status et. и др. было также немного подозрительно, и не совсем понятно, правильно ли работал этот процесс диагностики / восстановления на уровне ZFS / ZPOOL; конечно, я получил несколько смешанных сообщений о статусах ошибок и их очистке и т.д. и др. Признаки ошибок вроде как исчезли после перезагрузки, несмотря на отсутствие явной команды zpool clear; возможно, это и было задумано, но если это так, то это не было предложено выводом статуса zpool.
Потенциально, что-то более серьезное, кажется, что-то НЕМНОГО пошло не так во время работы после нескольких дней безотказной работы, когда большие части массива, содержащие несколько файловых систем (ZFS), просто "исчезли" из списка в (ls) и из-за обычного доступа ввода-вывода , IIRC df -h, ls и т.д. Не сообщали о файловых системах, даже если они существовали, тогда как состояние zpool list / zpool продолжало указывать ожидаемый объем использованного хранилища в пуле, но это не учитывалось ни одним из перечисленных подключенных или несмонтированные файловые системы. / var / log / messages не содержала никаких сообщений об ошибках, и операции до этой проблемы проходили совершенно нормально. Состояние zpool list / zpool не указывает на проблемы с пулом. Произошел сбой zfs unmount -a с указанием "занято" без видимой причины, касающейся интерактивного использования в течение нескольких минут, прежде чем отключится последняя из смонтированных файловых систем zfs. Перезагрузка и перепроверка / var / log / messages, статус zpool, список zpool не были информативными для какой-либо проблемы. Ранее отсутствовавшие файловые системы фактически перемонтировались, когда их просили сделать это вручную, и первоначально казалось, что они содержат правильное содержимое, но примерно через минуту после установки различных систем zfs в пуле было отмечено, что некоторые из них снова неожиданно исчезли. Возможно, что я сделал что-то не так с определением файловых систем zfs и каким-то образом вызвал проблему, но в настоящий момент я нахожу необъяснимым, что работающая система, выполняющая ввод-вывод в различные каталоги zfs, может внезапно потерять представление обо всей файловые системы, которые прекрасно работали минуты / часы / дни назад без каких-либо промежуточных команд sysadmin для изменения базовой конфигурации zpool / zfs.
Конечно, я использую стабильный моментальный снимок Feb'10, который НЕ рекомендуется для производственного использования, но опять же несколько стабильных исправлений известных проблем ZFS/ хранилища были добавлены в стабильную ветвь начиная с версии 8.0, поэтому запуск версии 8.0 может быть неудовлетворительный с точки зрения надежности / функций из-за этих проблем для некоторых людей.
В любом случае, всего несколько недель довольно легкого тестирования привели к достаточно потенциально катастрофическим проблемам с надежностью / функциональностью, не все из которых, по-видимому, связаны с конкретными недостатками накопителей / контроллеров / драйверов, которые я осторожно доверяю FBSD 8.0 + ZFS для производственной / надёжной работы без тщательно контролируемой конфигурации аппаратного и программного обеспечения и стратегии автономного резервного копирования.
OpenSolaris сейчас вообще не нужен, IMHO, даже если вы хотели его запустить - на самом деле существуют серьезные известные проблемы с дедупликацией zfs, которые в значительной степени делают его непригодным к использованию, и, как кажется, из-за этих и других проблем рекомендуется ждать еще несколько версий патчей, прежде чем доверять OpenSolaris+ZFS, особенно с системой дедупликации. B135/B136, похоже, просто отсутствуют без релиза, наряду с основным выпуском ОС 2010.03. Кто-то говорит, что Oracle просто не знает, что делать с расписанием, но что ожидаемые коды будут выпущены с опозданием, в то время как другие задаются вопросом, увидим ли мы когда-нибудь полный набор ожидаемых функций в разработке от Sun в виде будущих версий с открытым исходным кодом. Oracle дал переход в собственность / лидерство / управление.
ИМХО, я бы придерживался только создания зеркал, и только с очень хорошо проверенными / стабильными драйверами контроллера хранилища и моделей дисководов для оптимальной надежности ZFS под FreeBSD 8, и я бы, вероятно, подождал 8.1 даже в этом случае.
