Оригинальный - ftp://oss.sgi.com/projects/xfs/download/patches/2.4.19/xfs-2.4.19-all-i386.bz2 А насчёт моунта - не наю - у мня один раздел - ужэ 1,5 года на рейзере - всякий мусор ещё со слак 8.0 а рут и корень под хфс ужэ пол года и такого не заметил.

дык его и используем...

>>корень под хфс ужэ пол года и такого не заметил

плохо смотришь.
выдает примерно следующее :

RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 20k freed
cramfs: wrong magic
FAT: bogus logical sector size 0
UMSDOS: msdos_read_super failed, mount aborted.
FAT: bogus logical sector size 0
FAT: bogus logical sector size 0
You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|old|hp|nextstep|netxstep-cd|openstep ..
.

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
ufs_read_super: bad magic number
UDF-fs DEBUG lowlevel.c:65:udf_get_last_session: CDROMMULTISESSION not supported
: rc=-5
UDF-fs DEBUG super.c:1421:udf_read_super: Multi-session=0
UDF-fs DEBUG super.c:410:udf_vrs: Starting at sector 16 (2048 byte sectors)
UDF-fs: No VRS found
read_super_block: can't find a reiserfs filesystem on (dev 03:03, block 32, size
 2048)
read_super_block: can't find a reiserfs filesystem on (dev 03:03, block 4, size 
2048)
XFS mounting filesystem ide0(3,3)
XFS: WARNING: recovery required on readonly filesystem.
XFS: write access will be enabled during mount.
Starting XFS recovery on filesystem: ide0(3,3) (dev: 3/3)
Ending XFS recovery on filesystem: ide0(3,3) (dev: 3/3)
VFS: Mounted root (xfs filesystem) readonly.
Mounted devfs on /dev

: Последнее, что приходит в голову - попытаюсь пересобрать ядро,
: отключив оптимизацию (я обычно собираю с "-O3 -march=athlon-tbird").
: Хотя, я не особо верю в то, что это даст положительный результат

Не соит загонять ядро в оптимизацию, под которую оно не расчитано.
Но, скорее всего, дело не в этом.
Скорее всего, дело в компиляторе, иногда именуемом, как gcc-2.96.
Я прав, насчет используемого компилятора?

А монтирование root/boot partition с notail можно не делать,
если lilo > 21.1.6 (если правильно помню).  Для более точной версии,
надо смотреть на сайте reiser'а в FAQ.

-- awn

Ну не было у мня такого - всё путём.

А вот рейсер в корне посыпался таки через те жэ пол года - право я там такого намутил - при компиле ядра всет вырубили - а после перегрыза я его не make clean etc а прямо дальшэ make bzImage - и с него загрузился вот оно и посыпалось.

Проблема с ReiserFS

2 awn:

По поводу компилятора: несчастье, именуемое gcc-2.96, насколько мне известно, активно использовалось только в Red Hat. Я сам собирал свой дистрибутив и если бы я пользовался gcc-2.96, то, скорее всего, так никогда бы его и не собрал ;-( Я пользуюсь gcc-3.x.x (в данный момент 3.2.2) и стараюсь обновлять компилятор несколько дней спустя после выхода очередной версии. До перехода на третью версию gcc пользовался 2.95.3.

Я не уверен, что использование дополнительной оптимизации повредит ядру, если только gcc реализует оптимизацию корректно. У меня никогда не было из-за этого проблем. А оптимизация "по умолчанию" ядра Линукс, IMHO, имеет своей целью обеспечить беспроблемную сборку на различных семействах CPU|архитектурах. И потом, многие документы, например "Securing and Optimizing Linux", настоятельно рекомендуют "затачивать" параметры оптимизации под свое железо с целью добиться максимальной производительности за счет использования особенностей/преимуществ конкретного процессора. Хотя, особого прироста производительности я не заметил. По моим субъективным оценкам использование "-O3 -march=..." добавило 3-5% производительности. Но и это неплохо абсолютно на шару. И потом, тестов я не проводил, может быть получились бы совсем другие цифры.

2 saicat:

: По поводу компилятора: несчастье, именуемое gcc-2.96, насколько мне
: известно, активно использовалось только в Red Hat. Я сам собирал свой
: дистрибутив и если бы я пользовался gcc-2.96, то, скорее всего, так
: никогда бы его и не собрал ;-( Я пользуюсь gcc-3.x.x (в данный момент
: 3.2.2) и стараюсь обновлять компилятор несколько дней спустя после
: выхода очередной версии. До перехода на третью версию gcc пользовался
: 2.95.3.

OK.  Это исключает, заодно и вопрос о "правильно ли было
скомпилировано ядро?"

: Я не уверен, что использование дополнительной оптимизации повредит
: ядру, если только gcc реализует оптимизацию корректно.

Тогда остаются только два предположения:
1. gcc реализует эту оптимизацию некорректно.
2. какие-то проблемы с железом.

Что именно из этих двух -- не знаю.

Из моего опыта: на моей машине reiser "летал" только один раз --
когда физически посыпался HDD и в поврежденную зону попал в том
числе суперблок reiser'а.  При этом большинство данных (те, что не
попали в поврежденные зоны) удалось восстановить через
`reiserfsck --rebuild-sb' + `reiserfsck --rebuild-tree'
Т.е. код reiser'а, на мой вкус, достаточно надежен.
Компиляторы, которыми я пользовался -- те же самые (2.95.3, 3.2,
3.2.1, 3.2.2)

С другой стороны, все мои действия по оптимизации сводяться только к
тому, что я признаюсь на этапе конфигурации какой именно у меня
процессор (раньше был K6-какой-то, теперь Duron), а какие именно
ключи подставлять компилятору оставляю на усмотрение Makefile'ам
ядра.

Наверное, следует все-таки сначала попробовать не вмешиваться в
оптимизацию "вручную" (это реализуестся проще всего), а если не
поможет -- попробовать поменять железо, если есть такая возможность.

-- awn