Эндрю Мортон обнародовал краткий список грядущих изменения в Linux 2.6.14
Изменения затронули файловые системы OCFS2, relayfs, v9fs, а также pcmcia и scheduler
Помимо этого в ядро будет добавлены поддержка FUSE из -mm
С рейзером опять нелады
> reiser4
> Stuck. Last time we discussed this I asked the reiser4 team to
> develop and negotiate a bullet-point list of things to be addressed.
> Once that's agreed to, implement it and then we can merge it. None
> of that has happened and as far as I know, all the review feedback
> which was provided was lost.
Мой вольны перевод (поправьте, если что не так):
reiser4
Застряли. В последний раз когда мы обсуждали это, я попросил
рейзероскую команду написать и обговорить bullet-point
не знаю, что это) лист возможностей, чтобы на него ссылаться.
Как только он будет согласован, реализовать его и после мы
можем включить (merge) его в ядро. Но ничего из
вышеперечисленного не случилось и, насколько мне известно,
all the review feedback which was provided was lost. (на пальцах
понятно, но умничать не буду, может кто дополнит).
я бы себе R4 постпвил да ленивый стал, юзаю то что в дистре дают... Так что пока на reiserfs.
Что до стабильности, то думаю тут ты в самую точку попал. Он стабилен для десктопа. Я думаю даже на десктопе его очень трудно будет "завалить". Что до сервера наверно еще рано :)
мужики - а вот такая тема как quota support
что то с ней в рейзере неоднозначно - пишут что вроде поддерживается а вот в дистрах которые я видел (дебиан и альт, в сюзе не помню)- нет
Каждый раз после бурных обсуждений в очередной раз пытаюсь на новом разделе сделать ext3, но больше чем на пару месяцев не хватает (на разных машинах, разных винтах): в лучшем случае - глюки, чаще - полный п... и потом с матами на свою доверчивость переставляю на reiser, который за последние 3 года ни разу меня не подвёл, нигде, даже на "гнилом" железе.
Врядли тут "руки", я уже и объяснить не могу сей "феномен", объясняю разве что "несовместимостью":)
У меня на многих серверах стоит Ext3 (на ext2 сказали tune2fs -j, или хостеры поставили), особых проблем нет, поскольку на серваках ядра более стабильны, чем на десктопах. А на домашнем десктопе да, ловил как-то фишку... Но замерив скорость работы RAID0 из 6 скази дисков, остановился на XFS, 300Mb/sec мне нравятся больше, чем 170Mb/sec.
на сколько я помню раньше проскакивала новость что больше в ядра 2.6 никаких новшеств добовлятся небудет, а вся работа будет сосредоточена над стабилизацией ядра. Или это всё касалось только подверсии 13 ?
Да измеризмы у меня были ненаучные, специфические для моих задач -- хранения больших датафайлов от оракла. Сравнивал скорость последовательного чтения и записи на FS в сравнении с RAW. Специфика в том, что RAW представлял из себя software raid-0. На новом сервере попробую OCFS2.
>По скорости на МОИХ задачах чуть быстрее 3 райзера (чисто субьективно - тестов не проводил)
В рассылке PostgreSql несколько раз всплывала тема "быстродействия" файловых систем. Всегда побеждала JFS с отрывом 10%-15%. Сравнивалось время полной архивации + восстановления баз и ( что чаще ) vacuum full. Базы для постгреса не маленькие - порядка сотен гигабайт. Однако все заканчивалось на том, что приходил один дядька и говорил, что у него-де, базуха на JFS перманентно потихоньку сыпалась, что прекратилось при переходе на XFS... Хм ... хотя у нас оракловые датафайлы на JFS лежат и не жужжат...
Кстати часто спрашивают зачем нужен FUSE. Например SieFS (программа для работы с файловой системой мобильных телефонов Siemens) требует FUSE, и приходится постоянно компилить модуль для него.
>Однако все заканчивалось на том, что приходил один дядька и говорил, что у него-де, базуха на JFS перманентно потихоньку сыпалась,
У меня на память был только один маленький косячек. Как то пока я был в отпуску задачка забила 100 с лишним гигов диска на JFS под завязку и при очередной попытке записи честно сказав "а не лезет больше" - остановилась. Я по приходу на работу это дело увидел и мусор поудалял НО места на диске освободилось меньше чем было изначально. Видимо последняя недописанная порция "застряла". Пришлось диск отмонтировать и отчекать - после этого всё встало на место но никакой потери дынных или критичной потери целосности FS (когда FS тупо уходит в RO) как это на рейзере3 случается частенько не всплыло. То есть одна мелкая неприятность в стрессовой ситуации за 2 года. Я так и не понял, баг это или фича ;)
Я несколько раз описывал простые тесты скорости для рейзер4, рейзер, и ext3. С одного и того же раздела одного физического диска я копировал файл около 500 Мбайт на один и тот же раздел другого физического диска.
Уничтожал разделы и форматировал их заново. Рейзер4 копировал этот большой файл со скоростью где то 50 Мбайт/сек, около двух раз превосходя ext3 и рейзер. Скорость самого диска была на уровне 55-60 Мбайт/сек.
Скриптом создал подкатолог из 20 папок в каждой по 16000 файлов 1.1 Кбайт. Скорость копирования была на уровне 10-15 Мбайт/сек, при загрузке CPU до 60%. Рейзер опять копировал в 2 раза медленее, но CPU 30%.
Проводил тест Саныча на устойчивость :-)
во время копирования этого каталога отключал питание, разницы рейзер4 с рейзер не было. Вообщем система вполне готова как для десктопа, так для серваков.
После каждого копирования машины перезагружал. Все это на лоре я несколько раз писал.
ИМХО тест лучше бы сделать с копированием файлов с соотв. ФС в /dev/null и с /dev/{null,urandom} на соотв. ФС (чтоб получить чистое время чтения/записи). А тест с мелкими файлами лучше повторять с файлами random-размеров и повторить его на SCSI (там могут быть другие относительные результаты)
В твоём случае притестировании скорости записи влияет и скорость считывания, и наоборот. Если же ты считывать будешь "из ничего" и пысать "в никуда" (при тесте чтения), влияние сведётся к минимуму.