2Мещеряков Андрей:
Ваша категорическая неприязнь к мелким&мягким видна невооруженным глазом, но причем тут вообще ZFS? К этой мегакорпорации она, вроде бы, отношения не имеет.
Ваше утверждение, что скорость ФС уже более роли не играет - имхо не совсем верно. Естественно, часто куда как проще купить быстрое железо и забить на все остальное, но, глупо не выжать из него все возможное, устранив даже потенциальные bottlenack'и хотя бы в ФС. Чтобы на практике проверить собственные слова, я поставил маленький эксперимент.
Дано: Стенд, собранный на Sun Fire V440, Hitachi AMS200 (32x300Gb HDD), подключенный двумя прямыми FC-линками к серверу. На сервере включен round-robin loadbalancing, осуществляющий i/o на двух контроллерах поочередно. На хитаче создана райд-группа RAID0+1 из 4HDD, в ней 3 одинаковых луна. Конфигурация, согласитесь, не самая тормозная.
Сделано: На одном луне создаем файловую систему UFS. На два другие сверху наворачиваем ZFS пул-зеркало, и создаем в нем файловую систему ZFS. Пользуемся соларисным бенчмарком там и там. Потом на массиве отключаем один из лунов, который является частью ZFS пула, чтобы имитировать отказ HDD. Создаем новый лун (чистый) и отдаем ОС с тем же номером, чтобы митировать установку чистого HDD взамен испорченого.
Результат: Синтетический соларисный бенчмарк показал 10-15% прироста производительности на ZFS по сравнению с UFS в среднем на всех тестах, хотя на рандоме они были более заметны, чем на линейных операциях. После отключения луна ничего не происходит, ввод-вывод на него успешно продолжается, хотя в конфигурации появляется флаг degraded. При включении старого луна пул восстанавливался, при включении нового, чистого - автоматически начался процесс синхронизации.
Кстати, по заверениям Microsoft, в Vista они пойдут на "рассекречивание" своих ранее закрытых для сторонних разработчиков API. Естественно, не по своей воле - но тем не менее.
По поводу того, где сильнее Unix - не только в веб, уверяю вас