Вышла новая версия журналируемой файловой системы от SGI.
Исправления по сравнению с версией 1.2 можно посмотреть здесь - ftp://oss.sgi.com/projects/xfs/downlo...
Видимо, linux kernel еще не дорос до Irix. Одно дело - суперкластер, и совсем другое дело - монолитный многопроцессорный сервер.
> Ну хотя бы ту же XFS в полный рост ?
С одной стороны это технически, наверное, не так просто, а с другой стороны - а зачем? XFS в данном объеме большинство устраивает (этакий легковес), и не стоит гнаться за превышением соотношениям 80/20. Тем более, усложнение несет за собой падение скорости и стабильности. На Irix в основном использовались сказевые рейды, а на Linux - оччччень далеко не всегда. Глупо врубать все фичи XFS на домашней машине.
> Саныч, почитай заголовки в своих мессагах и смени наконец > броузер, если тебе тяжко настроить :)
Да ты чего ? Масяныч супер-пупер-хакер-админ, для него влом заняться таким элементарным делом, чтобы его броузер на фрюхе работал нормально и не подставлял заголовки из бог-весть каких трейдов
А под линухом ТОРМОЗИИИТ. И причем по страшному. Даже тестов никаких пускать не надо, оно так тормозит что даже иногда приходят мысли что там просто что-то циклится.
Это верно. У меня есть разделы с xfs, reiserfs, ext3 и один jfs. Я его просто так поставил, чтобы производительность посмотреть. Если кому-нибудь будет интересно могу скинуть результаты моего собственного тестирования. Коротко говоря: reiserfs на ide-диске 7,200rpm был существенно быстрее, чем xfs на 15,000rpm scsi. производительность jfs (2 с небольшим MB в секунду) была не только на порядок ниже чем reiser/xfs, но даже меньше чем nfs поверх ext3 на 100Mbps ethrenet.
> Меня всегда очень интересовало, почему SGI, которая выпускает
> суперкластеры под лялих64, не перелила в него все фичи из Irix ?
А что отсутствует в XFS на Linux в отличие от Irix? Навскидку вспоминаются только три пункта:
1) CXFS - слиент уже раздаётся за деньги, мастер пока только под Irix,
в общем и целом фича довольно нишевая.
2) Irix volume manager - а оно Линуксу надо? Линуксоидам бы со своим зоопарком разобраться сначала.
3) grio - цель, imho, недостижимая для универсальной OS, работающей на множестве различного железа.
А в остальном это та самая XFS, что и в Irix. Только вот покоцали её, пытаясь привязать SYSV VFS к линуксу нещадно, вот и характеристики и страдают.
стоит XFS(1.2 по-моему) на / (вся система на 1м разделе),
полгода назад переустановил систему на тот же раздел, все ок,
несколько раз выключался свет, пару раз приходилось запускать xfs_repair.
Производительность где-то как у ntfs в w2k.
А reiser еще страшно кроме как для тестов использовать.
А мне вот страшно xfs испольовать :) Свет вырубают пару раз в неделю и так получилось что в тот момент когда я тестировал xfs свет вырубили два раза подряд (вырубили на три минуты, затем влючили, и через 5 мин вырубили на весь вечер), как раз копировались какие-то файлы, играл xmms, мозилла работала ну и прочее. Вобщем раздел накрылся медным тазом, куча файлов исчезла безследно :) Потом уже прочитал что xfs страшно не любит внезапные отключения компа :) С рейзером же полет нормальный (тьфу-тьфу 3 раза :)) приходилось канешно пару раз тоже делать fsck.reiserfs --fix-fixable /dev/hda2 после серии перебоев с питанием, но все файлы были на месте и раздел живет до сих пор. Естесно все ето не флейма ради, а беседы для :)
в режиме 8 выключений за вечер(6ка, северное крыло зимой) ext3 жил 2 года, и хоть бы хны... но сейчас пользую xfs на буке с плохой батарейкой, тоже тьфу-тьфу-тьфу
[2003-08-23 17:12:09.902222]
тоже не ради flame, мой опыт показывает что тут как повезет,
бывает и пару раз подряд на xfs с большой текущей загрузкой (make -j5)
выключают свет и хоть бы хны,
XFS mounting filesystem ide0(3,8)
Starting XFS recovery on filesystem: ide0(3,8) (dev: 3/8)
Ending XFS recovery on filesystem: ide0(3,8) (dev: 3/8)
а бывает и пополнение в lost+found после xfs_repair ;(.
имхо xfs пока лучшая, надо бы крэш тест для journaled FS провести ;).
2003-08-23 17:12:09.902222
в режиме 8 выключений за вечер < да, прикольно было
и че, apmd/acpid не спасают мобильных хацкеров
;)?
ой YO IO IO, батарейка :)))
кстати и сервер наш, который в южном крыле стоит везде имеет XFS.
я тестировал все эти ФС - по сравнению с ext2 это все полное гавно, на нормальном питании от розетки хорошей не нужны журналы никакие и поэтому ext2 быстрее.
>>>по сравнению с ext2 это все полное гавно ..... У тебя видно партишен под ней чуть побольше размером флопика. e2fsck на плотно забитом партишене рамеров гигабайт 100 будет продолжаться пару суток - так что не надо нас маленьких дурить ...
Производилось копирование dd if=/dev/zero of=fill.space bs=4096 на RAM диск обьемом 800Мб. Каждый раз на диске создавалась новая файловая система, копирование производилось 20 раз, результат усреднялся. Результаты:
Reiser - 0m24.364s
Ext2FS - 0m34.659s
XFS - 0m43.913s
JFS - 1m0.376s
Kernel 2.4.21-RC2-AC3 on Athlon 2600+/1Gb DDR400 ram
>>>Про тесты с ram disk - полная туфта. Почитай что-нить про OS
Ээээ как бы помягче сказать что вы, батенька, полный дебил. И при чем тут чтение про OS ? Если у вас имеются какие-нибудь соображения по поводу методологии тестирования - изложите их более внятно. А я постараюсь обьяснить вам в чем заключается ваша некомпетнность в данном вопросе.
Я согласен с одним из предыдущих товарищей, что time dd это не показатель. Здесь абсолютно не учитывается скорость создания и удаления файлов, поиска в директории и т.д. Когда я сравнивал 4 журналируемые файловые системы я использовал postmark несколько раз с разными параметрами. Потому что time dd может просто записать файл в буфер, если он достоточно маленький и никаких дисковых операций реально выполняться не будет.
Да пропустил. dd на RAM-диск?? То есть время подвода головок и т.д. в принципе не учитывалось? Только сколько времени сама система тратит на то, чтобы код драйвера выполнять? И что же такое "тестирование" измеряет?
Тесты файловой системы проведенные на "реальном" диске будут отражать в первую очередь его латентность, а показатели быстродествия фаловой системы будут присутствовать как составляющая на порядок меньше от общего времени, кроме того на всех операциях чтения будет сказываться влияние системного кеша. тест приведенный выше, никоим образом не претендует на полноту - но он наилучшим образом иллюстрирует бытродествие FS - именно того пресловутого драйвера упомянутого выше.