Архитектура и реализация файловой системы reiser4

> Мы ему отдельный создадим Intel Core 2 Duo vs Athlon 64.

Название топика не отражает действительности. Лучше назвать "Избиение младенца".

Если падает ext3 - это 100% железо.

> Название топика не отражает действительности. Лучше назвать "Избиение младенца".

Да уж. Словами младенца глаголет истина ;)

>Вывод. Все файловывые системы одинаковы.

неправда! никто не видел как накрывается диск или контроллер? я видел несколько раз... в результате этой неприятности, нет НИКАКОЙ возможности отмонтировать збойный (или мертвый) дивайс из за постоянных попыток синхронизации - выход один - перемонтировать все живые дивайсы в r/o и перетолкнуть сервак кнопкой - такой вот закат солнца в ручную. ну да ладно. все бы хорошо, однако на одном из серваков недавно здох диск. ну здох не здох, а перестал вращаться. а там тэйбл спейс базухин ... xfs там фйловой системой работал. и что бы вы думали? на консоли надпись примерно такого плана "I/O error detected. Shutdown filesystem." - файловая система зашатдаунилась (не отмонтировалась, а именно зашатдаунилась) и никакого гемороя! я потом посмотрел в коде - похоже так умеет только xfs (jfs вроде тоже так делает если происходят ошибки записи-чтения в журнал)! после обычной перезагрузки "дохлый" диск волшебным образом раскрутился и тэйблспейс был с него удачно слит (оказался вполне себе живым). xfs - самая крутая файловая система! ура!

> Судя по всему в 4 версии таких фишек (plugin) будет ещё больше.

Судя по всему, четвёрка станет совместима сама с собой. Т.е. rfs4 от одного дистра не подходит к rfs4 от другого... :-(

>Тоесть хотите сказать, что дана команда драйверу и ни чего не происходит? А в случае с ext3 такая команда не дается?

:)

"Why doesn't ext3 get hit by this? Well, because ext3 does physical block journalling. This means that we write the entire physical block to the journal and, only have the updates to the journal are commited, do we write the data to the final location on disk."

"XFS and Reiserfs do what logical journaling. This means that if you modify the mod time of an inode, instead of writing the entire inode table block to the journal, instead, they just write a note in the journal stating that "inode X now has a mod time of Y". This takes much less space, and so you can pack many more journal updates into a single disk block."

>Кстати да, на fat32 под windows я такого не видел.

батенька да вы слепой наверное? или мало с компом общались во времена fat32

такого можно было насмотреться - мало не покажеться :)))

не знаю что значит "файловая система зашатдаунилась ",
но в Linux в случае фатальных ошибок драйвер файловых систем вызывает
что-нибудь типа ext2_panic и происходит автоматическое перемонтирование
FS в read-only

Помоему ext3 тоже умеет шатдауниться.. Не буду утверждать, но в своё время сталкивался с этим. Хотя это было давно и я мог перепутать, но помоему такое есть в ext3 по крайней мере в ядрах Редхата.

Это задается в опциях при создании-тюнинге ext2/3, error behavior, "поведение при сбое", проще говоря. Можно поставить и кернел паник, и ремаунт в р-о.

>не знаю что значит "файловая система зашатдаунилась ",

И я незнай! Гы-гы-гы-гы!!!

/*
 * Force a shutdown of the filesystem instantly while keeping
 * the filesystem consistent. We don't do an unmount here; just shutdown
 * the shop, make sure that absolutely nothing persistent happens to
 * this filesystem after this point.
 */

void
xfs_do_force_shutdown(
	bhv_desc_t	*bdp,
	int		flags,
	char		*fname,
	int		lnnum)



>но в Linux ... что-нибудь типа ext2_panic драйвер файловых систем вызывает  и происходит автоматическое перемонтирование FS в read-only


хе-хе-хе! а что такое "драйвер файловых систем" ась? не поделитесь?
а если серьезно - ни разу не посчастливилось наблюдать  как при 
ошибках i/o ext2 например неремонтировалась в r/o.  тем более
сомневаюсь что она будет "keeping the filesystem consistent". 
все больше както попадалось что то вроде 

"umount - attempt to sync device bla-bla-bla failed!"
"umount - attempt to sync device bla-bla-bla failed!"
"umount - attempt to sync device bla-bla-bla failed!"
...
"umount - attempt to sync device bla-bla-bla failed!"

>Да и какая инфа может быть кроме записать туда-то, считать оттуда-то..
>Я не кернел факер, чтобы сильно сыпать аргументами...

ваш пост звучит как не читал, не знаю, но осуждаю,
может стоит что-то узнать перед тем как высказывать свое мнение?

для журналируемых ФС, как минимум нужна возможность не только читать и записать, но и записать, что-то после того как было записано что-то,

например то что сначала на диск попадет запись журнала, а потом данные,

в обычных ФС, если какие-то данные не попали на диск, до внезапной перезагрузки,
хотя по идее они должны быть, ничего заметного не случиться,
в случае же reiser можно обраружить часть файла в другом.

К тому же несколько раз в драйверах диска в linux были ошибки,
и проблемы возникали не только на reiser, но и jfs и xfs, но
reiser более популярна, и поэтому о ее проблемах больше известно.

AcidumIrae:

И что? К чему было эт сказано? Это показывает, что reiser хотябы так-же надежен как ext3? Или что мне показалось, что машина не работала, т.к. просто не загрузилась, из-за того, что каталог /usr/lib был мертв?

Lenin: Ты мне еще посоветуй hex dump диска глянуть... А то мож там всего пару бит поправить и все ок. Файлуха то супер! Быстрая как ни кто другой...

З.Ы.: Что такое debugfs я "слышал".

>Можно поставить и кернел паник, и ремаунт в р-о.

В свое время так и не нашел как можно отучить freebsd впадать в панику,
если с одиним из нескольких дисков "что-то случилось".

Извините, что "я так звучу".

Тоесть запись журнала на устройство принципиально отличается от записи данных на тоже устройство, но в другую область. И используются совсем другие "механизмы" записи. Так? Спасибо, не знал. Тогда все ясно. Тогда понятно почему "правильная и замечательная" reiserfs не работает. По другому не могу сказать. Сорри.

Если данные одного файла оказались в другом, значит не все "журналировалось". Такое я наблюдал 100 раз на Fat12,16. На 32 не припомню... возможно было. На ext3 опять же ни разу не замечал.

Я и не говорил, что спец по ФС хоть какой-то. Но имею мышление, и немного им пользуюсь... ;) И кое-что все-таки знаю.

Если находились ошибки - они исправлялись. И даже я на своей рабочей лошадке нарывался на ядра с этим, хотя и не заметил ни чего. И как работала ext3 так и работает. Верю что просто повезло. Но на ядрах, где небыли (в анонсах не писали) замечены ошибки, та самая замечательная ФС падала. Глупый вопрос: Что я делаю не так? Хотя он меня и самого раздражает.

Статья в целом неплохая но что называется галопом по европам. Основные замечания с моей стороны такие:

* я бы сфокусировался на фичах, необычных свойствах и выводах, что можно сделать имя эти фичи, а уж дисковые структуры или как эти фичи реализованы подтягивал бы по мере необходимости. Например, можно было сказать что если журнал безразмерный (теоретически) то можно реализовать такую фичу как freeze. То есть админ говорит reiser4.freeze и все изменения падают в журнал до тех пор пока не сказали reiser4.unfreeze. Для чего это нужно? Да хотя бы для бекапов без остановки серверов.

Ну или есть такая вешь repacker, он омжет не только перепаковывать дерево в онлайне а еще и например при незначительных усовершенствованиях делать чтото типа on-line resize via journal. Там еще оч. много таких приколов. Например в фибрами тоже.

* некоторые определения не совсем верны. Нарпимер сказано что atom это любое изменение. По моему мнению atom это набор изменений связаных по контексту. То есть не просто транзакция в кот. попадает запись файла и одновременно обновление stat-data. Это атомарное, более слжное изменение данных причем оно полностью в контексте работающего приложения.

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

Да, без отображения свойств на их реализацию материал становиться зачастую абстракным

>или мало с компом общались во времена fat32

Я не говорю что windows не падал :). Просто падений из-за ошибок в собственно драйвере fat32 я не видел.

>Я не говорю что windows не падал :). Просто падений из-за ошибок в собственно драйвере fat32 я не видел.

вот я и говорю - мало вы видели ;)

>И что? К чему было эт сказано? Это показывает, что reiser хотябы так-же надежен как ext3? Или что мне показалось, что машина не работала, т.к. просто не загрузилась, из-за того, что каталог /usr/lib был мертв?

:))) это было на тему "why-reiserfs-is-teh-sukc" (c) Theodore Ts'o - tytso@mit.edu

>Theodore Ts'o

а он не один из разработчиков ext2/ext3?

> В свое время так и не нашел как можно отучить freebsd впадать в панику, если с одиним из нескольких дисков "что-то случилось".

Речь кажется шла о linux+ext2/3, причем здесь фря?

А так - хз, мне все никак не удастся столкнуться с реальным крахом файловых систем ext/reiser/xfs... наверное я что-то делаю не так :)

Вот с reiser4 - было и не раз, убивалось дерево, корраптились отдельные блоки данных, генерились oops'ы в бешеных колическтвах и т.д.

>А так - хз, мне все никак не удастся столкнуться с реальным крахом файловых систем >ext/reiser/xfs... наверное я что-то делаю не так :)

хотите патч вышлю? :)

>Вот с reiser4 - было и не раз, убивалось дерево, корраптились отдельные блоки >данных, генерились oops'ы в бешеных колическтвах и т.д.

а откуда брали, имеется ввиду -mm ветку или на vanilla накладывали?

> Но на абсолютно исправном железе, на машине где небыло упса рейзер 3.6 сыпался. это факт. возможно из-за выключения питания. замечу - не 1 раз.

А у меня за три года 3.6 без упсов с неоднокретным пропаданием питания не сыпался ни разу на действительно исправном железе. Что я делаю не так?

> Только не надо говорить, что всетаки железо. Проверял 3 раза до установки и 3 раза после сбоев. Железо нормальное.

Как проверял? :)

> После неоднократных падений поставил все на ext3. Пошел 3й год как я не слышу про те машины... боюсь даже угадать почему...

Венду поставили?

> У рейзеров есть не малык плюс, о котором стоит помнить. Они умеют упаковывать "хвосты" файлов. Т.к. на типичной Unix системе количество файлов довольно велико, то на "обычной" FS имеем огромный slack. Если принять размер блока равным 4k. То при количестве файлов порядка 800000 (как у меня на "/"), получаем slack --- ~1.5Gib.

1.5Gib ха ха как мелко. И что мне теперь на 4-х HDD по 400Гигов из-за этого париться с глюкало-райзером?

> хотите патч вышлю? :)

Да ну вот еще, рушить ФС посредством патча - некошерно и ненаучно :)

> а откуда брали, имеется ввиду -mm ветку или на vanilla накладывали?

Разумеется vanilla + патч с фтп-шника namesys, в -мм слишком много мелких патчей, чтобы заморачиваться с ними, а патчить целиком - ануннах, не стоит оно того.

> 1.5Gib ха ха как мелко. И что мне теперь на 4-х HDD по 400Гигов из-за этого париться с глюкало-райзером?

Не слушай еретиков, сын мой, я скажу тебе что есть правда :)

А правда в том, что сборка ОпенОфиса из сорцов обваливается по причине недостаточного места еще на стадии создания инсталляционных образов на 8Gb ext3, но под reiserfs 3.6, монтируемым по дефолту (defaults,xattrs,noauto - никаких notail и прочей ереси) - остается свободным порядка 3.5-4Gb. Экономия в 2 раза на туче мелких файлов - причем их куда меньше, чем 800k, скорее 80k (max). И потеряешь ты не 1.5Gb, а цельных 2 своих замечательных винта, ежели будешь разводить помойку ;)

>хотите патч вышлю? :)

к "драйверу файловых систем?"

>разработчики Suse копались в reiser3, и в основном их вина в нестабильности его в ихних дистрибутивах.

Пользую SuSE c 6.4 до 10.1 , рейзер использую с 7.3 ни разу ничегj небыло с файловой системой , какието сказки вы рассказываете странные , темболее о разработчиках SuSE которые если мне не изменяет память первыми вкрутили его в дистрибут и очень активно его поддерживают

chodorenko

>> У рейзеров есть не малык плюс, о котором стоит помнить. Они умеют упаковывать "хвосты" файлов. Т.к. на типичной Unix системе количество файлов довольно велико, то на "обычной" FS имеем огромный slack. Если принять размер блока равным 4k. То при количестве файлов порядка 800000 (как у меня на "/"), получаем slack --- ~1.5Gib.

>1.5Gib ха ха как мелко. И что мне теперь на 4-х HDD по 400Гигов из-за этого париться с глюкало-райзером?

Если забивать их фильмами или ISO-шками, то нет. А если файлы сравнительно мелкого размера, то можно и подумать. Я, кстати, померял реальный slack на своем корневом рейзере. При 40GiB размере и ~800000 файлов получил ~700Gib slack'а. На ext2/3, XFS, JFS было-бы 1.5GiB.

Учитывая, что проблем со стабильностью у меня не было, и по производительности reiserFS как минимум не хуже остальных, размер становиться решающим фактором.

>При 40GiB размере и ~800000 файлов получил ~700Gib slack'а. На ext2/3, XFS, JFS было-бы 1.5GiB.

Скажите, вам не кажется, что здесь что-то не так? =)

>разработчики Suse копались в reiser3, и в основном их вина в нестабильности его в ихних дистрибутивах.

Стоит Suse 9.3 уже третий год и четыре Promise VTrak 15100

reiserfs 3.6 и никаких проблем..... разве что 3 загнулись - заменил на горячию....

fileserver:~ # cat /etc/fstab

.............

/dev/sdb1 /raid_a reiserfs noauto 1 2

/dev/sdc1 /raid_b reiserfs noauto 1 2

/dev/sdd1 /raid_c reiserfs noauto 1 2

/dev/sde1 /raid_d reiserfs noauto 1 2

fileserver:~ #

fileserver:~ # df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda2 33G 15G 19G 43% /

tmpfs 1.7G 0 1.7G 0% /dev/shm

/dev/sdb1 4.8T 3.6T 1.2T 75% /raid_a

/dev/sdc1 4.8T 3.6T 1.2T 75% /raid_b

/dev/sdd1 1.9T 1.7T 173G 91% /raid_c

/dev/sde1 1.9T 1.5T 379G 80% /raid_d

fileserver:~ #

хотел так сказать:

"разве что 3 хард-диска загнулись"

Вот такая плохая рейзера, сломала три винта, нужно было ставить ext3! ;)

Любопытно, почитаем.. ;-)

Что, пля, за обсуждения? Пока Reiser4 нет в Slackware все обсуждения считаются преждевременными. :)

>> Мы ему отдельный создадим Intel Core 2 Duo vs Athlon 64. >Название топика не отражает действительности. Лучше назвать "Избиение младенца". >lenin # (*) (24.07.2006 15:11:19)

Ну почему же? Есть и у Intel сильные стороны

А я думаю тут вопрос в везении. Потому что у меня без упса рейзер стоит лет 5. Претензий никаких. Разные дистрибутивы стояли. Слака, дебиан, арх линукс с соответсвенно разными ядрами. Электричество выключалось часто. И все ок. =) Имхо чисто теоретически екст3 тоже может посыпаться. Как кому повезет.