JFS портируют под OpenSolaris

Её туда из aix принесли.

Не знаю, довали ли тебе уже эту ссылку, или у тебя просто кнопка западает, но вот, на всякий случай: http://www.paul.sladen.org/pronunciation/torvalds-says-linux.mp3

>>Для облегчения миграции с AIX и линакс.

Шутишь? Нет в этом мире таких причин, кроме одной - нема бабла.

Просто zfs и понятие скорость несовместимы.

>Им jfs только для совместимости нужна, или еще для чего-то?

Линукс стал мэйнстримом, а на мэйнстрим всегда в какой-то степени ориентируются в плане совместимости (см. многочисленные попытки прикрутить что-нибудь к линиксу для достижения схожести внешного вида и функионала/форматов венды). Даже такие "энтерпрайзщики", как Sun.

А тоже использую ext3 под систему. А для разделов больше сотни гигов - желательно jfs. Больше терабайта - только jfs. На reiserfs3 в свое время держал систему, но слишком она стремная, разные мелкие глюки (к примеру, нестандартный синтаксис и поведение fsck) и поведение, отличное от более стандартных "фс" в ряде ситуаций вызывали проблемы и заставили сползти с нее - тем более что вскоре вышел ext3, а потом и догнал reiserfs по скорости.

А на больших разделах в линуксе по любому только две фс разумны, xfs и jfs. Я раньше использовал xfs, но потом ушел на jfs (кстати, не один я, многие, использовавшие xfs поступали так же) - xfs конечно очень клевая по фичам и скорости, но слишком хрупкая и, видимо, слишком сложно устроенная, потому что может при определенных повреждениях так мистически глючить, что и представить себе трудно, что такое вообще возможно. jfs намного проще и совершенно неубиваема, где-то с 2003 года использую как фс для больших разделов на разных системах и не имел ни одной проблемы - конечно, легкие повреждения возможны, как и у любой фс в безупсовой конфигурации или на глючащем железе (битая память и прочее), но никаких "хитрых" состояний, которые я видел на двух или трех фс за год использования xfs, я не видел. Со временем перевел везде xfs на jfs, reiserfs на ext3 и стало намного спокойнее. Теперь создаю только ext3 и, когда того требует ситуация, jfs. xfs хороша, но нам с ней не по пути, а c reiserfs'ом я больше никогда в жизни ни в какой инкарнации не буду связываться и никому не посоветую.

В будущем, возможно, у ext4 будут шансы самой подходящей фс и для тех ситуаций, где сейчас оптимальна jfs - посмотрим.

Почему?

zfs такая тормозная за счет постоянных принудительных sync'ов и других методов обеспечения консистентности. Есть опции, чтобы это отключить - после этого она взлетает. Надежность, соответственно, падает, но вряд ли становится принципиально хуже, чем на том же jfs из коробки.

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

Просто, еще не настало время использования zfs в мейнстриме - обычное железо еще недостаточно круто для нее. Но учитывая прогресс в развитии ssd и прочее, думаю, со временем она будет намного интереснее всего остального, что сейчас есть - а новые разрабатываемые фс в будущем пойдут по пути гарантии высокой надежности в ущерб скорости, как и zfs сейчас.

Что мешало сразу не портировать это глюкало в линукс, а писать 'с чистого листа'... быдлоibmкодеры...

JFS1?

Под линуксом сразу JFS2 был, хоть и назывался просто jfs.

А, вообще, глюки полуоси нам не указ..

А смысл? Если фс создана для хранение данных с высокой надежностью, то нет смысла использовать ее в других целях (т.е. ускорять, отключая все подряд).

>Просто, еще не настало время использования zfs в мейнстриме

Просто нет необходимости ей вливаться в мэйнстрим. И думаю в ближайшее время такой необходимости не появится.

Ну прям как в советской сказке: "Сидоров Иван Петрович Член Имеется" =)

Юзаю ReiserFS дома и на работе. Нареканий нет. Отключения питания были.

Нет, конечно. У меня на 2.6.24-rc8 система из астрала данные брала. Кому libastral.so выдать? ;)

Где лет 10 назад, при переходе на 64бита были хорошие тесты - которые показывали, что операции с превышением разрядности процессора в два раза дают в среднем замедление задачи на 20%. И как недавно тут пробегали тесты - на столько же медленнее 128-битная zfs. И я им верю.

>Просто, еще не настало время использования zfs в мейнстриме - обычное железо еще недостаточно круто для нее.

А на дорогом железе потребность в zfs отсутствует, т.к. оно само делает большие рейды, расширенные контрольные сумы, снапшоты и многое другое, как раз jfs и xfs на нем вполне адекватны (а можно еще вспомнить vxfs).

К логопеду, быдло!

+1, на ноуте и на десктопе.

Всё верно: ZFS - для понтов и пиара, JFS - для скорости и надёжности.

Переход переходу рознь. Это так на спарках и пауэрах (где и по сей день пытаются использовать 64-х битное ядро + 32-х битную систему + 64-х битные приложения, которым нужно много гигов оперативки - полная 64-х битная система сливает по скорости), ну и верно в общем случае - но конкретно случился переход i386->x86-64 без этого замедления, даже с ускорением, потому что помимо чистого расширения регистров увеличили их количество и подлатали мелкие проблемки.

> И как недавно тут пробегали тесты - на столько же медленнее 128-битная zfs

Брр. Внутренняя разрядность структур фс, 32 она, 64 (как у большинства современных) или 128 очень слабо кореллирует с ее скоростью. Вернее, вообще не кореллирует - это же не криптография или другая числодробильная задача - ну будет чуть медленнее выполнятся, делов-то.

zfs на записи медленнее (иногда - сильно медленнее) из-за подхода, поставившего консистетность данных при любых обстоятельствах во главу. На чтении там нет особых проблем..

а взять готовый лицензия не позволяет?

> Не знаю, довали ли тебе уже эту ссылку, или у тебя просто кнопка западает, но вот, на всякий случай: http://www.paul.sladen.org/pronunciation/torvalds-says-linux.mp3

не поможет, т.к. это суныч

а разве этим не может заняться logrotate?

у него в конфиге есть параметр "compress"

>а разве этим не может заняться logrotate?

>у него в конфиге есть параметр "compress"

и в результате наблюдать вот эту петрушку вместо трех файлов:
-rw-r----- 1 root root   1213 Ноя 16 11:30 /var/log/acpid
-rw-r----- 1 root root    398 Ноя 12 18:10 /var/log/acpid.1.gz
-rw------- 1 root root    199 Фев  7 11:50 /var/log/messages
-rw------- 1 root root  70952 Фев  7 11:40 /var/log/messages.1.gz
-rw------- 1 root root  53106 Янв 31 16:20 /var/log/messages.2.gz
-rw------- 1 root root  20149 Янв 24 10:40 /var/log/messages.3.gz
-rw------- 1 root root  10101 Янв 16 12:41 /var/log/messages.4.gz
-rw-rw-r-- 1 root utmp 131328 Фев  7 10:45 /var/log/wtmp
-rw-rw-r-- 1 root utmp   8050 Фев  1 16:30 /var/log/wtmp.1.gz

где-то с 2001 года использую xfs как фс для больших разделов на разных системах и не имел ни одной проблемы. и?

У меня на xfs, когда закончилось место или что-то в этом роде, начали появляться файлы или каталоги с "мусорными" названиями, с которыми ничего нельзя было сделать, а fsck их игнорировал.

По сцылке логопед ?

Во приколу-то будет, если сановские юзера, привыкшие к стабильной работе соляриса будут тормозить и терять данные из-за бимерского убогого поделия!

Смеялся! Просто под стулом!!! :))))

Помню-помню, как бимерская отстойная "полуось" падала. Забыли своппер криворукие бимеры защитить в HPFS. Можно было переписать своппер вручную - и кирдык!

Нет и не будет у людей, имеющих хоть минимальный опыт с бимерскими поделиями, доверия к продукции компании болтунов и пиарщиков!

Специально для труЪ поясню: это будет опенсолярное поделие, код IBM не будет использоваться (формально, это не порт, а clean-room reimplementation).

Да и не беспокойся - даже этого не будет :) Просто какой-то бразилец решил себя пропиарить :D

ЛОР-врач?