Мимо. Я учился администрировать сервера с FreeBSD еще в те времена, когда она была версии 4.0, тогда же начал первые попытки программирования ( простенькие сетевые и не очень приложения на C ).

>Кстати если уж о серьезном
> применении говорить - почему-то в списке рассылки нжинкса предостаточно типов которые
> уверены и в том что в BSD ZFS тоже не очень
> как-то для серьезного применения.

Я с nginx почти не знаком, но могу предположить, что это все потому, что ZFS очень любит откушать побольше памяти для своего кэша, и nginx тоже по идее должен для скорости кэшировать в памяти всякое. Причем взгляды о том, что именно должно лежать в памяти, у них могут и различаться. Об универсальности ZFS лично я бы говорить не стал; есть вещи, для которых UFS подходит больше.

Можно подумать серьезные применения ограничиваются одним нжинксом.. И проблемы с использованием sendfile - это скорее проблемы интеграции ZFS и VM, если уж на то пошло.

"Давно" это с какого года?

> Кстати, спрашиваю из чистого любопытства, а как можно показать пул, теряющий данные?

"zpool status", естественно, а затем "uname -a".

> Сфоткать винты? Или полный дамп всех девов выложить?

Можете ещё фоточки приложить для разнообразия, как здесь:
http://forum.ixbt.com/topic.cgi?id=11:42325-15#415

Извините, что встреваю в высокую беседу, благородные доны. Вопрос к User294: ext4 уже умеет делать снапшоты на уровне файловой системы, как это умеет делать "ископаемый булшит" уже лет 8 как? В Ext4 уже можно не опасаться потери данных при open c O_TRUNC? Ext4, в отличие от своего предка ext3, уже сбрасывает дисковый кэш на каждый вызов fsync или все еще не на каждый (с целью обмануть бенчмарки или какой-либо еще)? Ext4 при open с флагом O_SYNC уже делает полную запись и данных, и метаданных на диск на каждом write или, как его предок ext3, использует читерские приемы и забывает обновить метаданные, если изменился только timestamp?

Откровенно говоря, смешно видеть, как ты провоцируешь стёб над успешно решённой проблемой, которая относится к аварийному (FAULTED) пулу. Я же не виноват, что ты не различаешь FAULTED и DEGRATED пулы.

(Даю подсказку, чтобы ты не попадал в будущем в просак: массивы RAID на Linux в состоянии FAULTED не подлежат восстановлению вообще.)

> ЗЫ как там твой ынтерпрайз на ноутбучных дисках поживает?

Отлично. Фильмами занято 99% полезного объёма. Буду постепенно смотреть и освобождать место для новых. :)) (Знаю: явно не для этого предназанчены RAID, но почему бы не поэкспериментировать и не ощутить "тормоза" и "гибкость" управления ФС, если есть такая возможность?)

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

Не понял.

Ха, ты бы еще на zfs-discuss пальцем показал, там таких историй было еще до "счастливчика на лисяре". И при этом со счастливым концом, в большинстве своем. Несмотря даже на отсутствие fsck.

Тебе хоррор-сториз про extX, reiser, xfs, btrfs etc помочь найти или сам справишься?

Кстати, важное отличие ZFS от зоопарка линуксовых ФС в случае серьеезного попадалова состоит вовсе не в том, что для ZFS нет fsck (как ты мог подумать), а в том, восстанавливая данные из ZFS ты можешь быть уверен в том, что это твои данные, а не какой-нибудь мусор (в случае мусора получишь ошибку ввода-вывода). Для extX и прочего ты после fsck получишь нечто, которое, возможно, удастся смонтировать и система не упадет. Но что там с целостностью файлов - тебе придется выяснять вручную. Хорошо, если в приложении есть механизмы проверки. А если нет, то после успешного fsck тебя будет ожидать масса увлекательного альтернативного секса по поиску причин всевозможнейших глюков :)

Справедливости ради можно отметить, что в btrfs то же есть контрольные суммы, и если они не отключены, то можно получить все те же плющки, но она все еще в разработке, а поэтому говорить о сколь-нибудь серьезном использовании пока не приходится.