Я использовал 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 в пуле было отмечено, что некоторые из них снова неожиданно исчезли. Вполне возможно, что я
Конечно, я использую стабильный моментальный снимок 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 даже в этом случае.