LINUX.ORG.RU

ReiserFS 4 Final Version


0

0

Наконец то вышла финальная версия одной из самых стабильных и надежных файловых систем - ReiserFS 4.

Описание финальной версии с сайта производителя:

# Reiser4 is the fastest filesystem, and here are the benchmarks.

# Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.

# Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.

# Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....

# Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function.

>>> Подробности от NAMESYS



Проверено: mator ()
Ответ на: комментарий от anonymous

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

И что ? У меня 4 production сервера за день создают по 20-30 тысяч маленьких файлов и вечерос их удаляют. И все в ажуре

bumpa
()
Ответ на: комментарий от jackill

вот именно!

> Тридцать метров в секунду она выдает

Именно поэтому место ей -- у параши, да еще на машинках у пЫонеров-хацкеров...

Dselect ★★★
()
Ответ на: комментарий от jackill

> Все пропустили важную вещь - у Саныча есть линукс, да еще и
> с рейзером

Не есть, а был. А судя по "Разве можно за старым человеком гонятся по фсем этажам?", был он явно не у него :)

anonymous
()
Ответ на: комментарий от Unixphreak

> /dev/hda: Timing buffered disk reads: 168 Mb in 3.03 seconds = 61.44 MB/sec

А при чем тут ФС?

> руки выпрями карапуз :-)

Дык ext3 не я писал...

Dselect ★★★
()

LOL %^))))

"одной из самых стабильных и надежных файловых систем"

Я плакалъ ;) Ну почему они не написали "reiser4 -- самая быстрая", а написали такое вот? :)))))

Приколисты ;) Хотя, они ее может быть с FAT32 сравнивали :)

Простите за флейм, но когда я прочитал вступление, меня прорвало %^)

Harliff ★★★★★
()

Народ, вы определитесь все таки, стабильна reiser3/reiser4 или нет! У кого там что падало? Вспоминайте подробности: какая версия reiser'a, что именно делали для ее убивания, какие фичи reiser'a использовали, какое ядро. И прочее и прочее. Нужно все-таки определиться, стабильна эта ФС или нет. Вобщем тест в студию (желательно что-бы не два часа тестилось), если можно (очень хочется).

А то одни говорят стабильна, серваки держим, другие -- нифига, падает только так...

Да, я там до этого посмеялся над фразой "Наконец то вышла финальная версия одной из самых стабильных и надежных файловых систем - ReiserFS 4". Это я не со зла, просто как то смешно очень стало... Я бы хотел, что бы resier4 нормально запахала (ибо переспективная весчь), но использовать ее в качестве основной ФС пока не хочется (боязно немного, старая добрая проверенная временем ext3 тормознее, зато по надежности к ней нареканий никаких нет).

Ах, да: если у кого-то глючное железо (проц разогнан сильно, память глючит, винт с бэдами, мамка noname и блок притания никакой), то именно он должен проводить основные тесты reiserfs на надежность ;)

У меня есть глючная память и я могу на ней reiser протестить, только скажите как именно. (я тред до конца еще не дочитал, может там про это именно говорят).

^)

Harliff ★★★★★
()

Люблю я заявления в стиле мы самые быстрые вот бенчмаки - для любой поделки сожно сделать бенчмаки которые показывают что она самая быстрая.

Опять бенчмаки в стиле копирования директории из 10000 файлов. Кому это нужно ?

Возможно она и будет самая быстрая для файловых серверов но ими все не заканчивается. Надо будет посмотреть как релиз работает с базами данных супер технология атомарных модификаций базируется на теневых страницах а это как известно страшенная фрагментация. Удалось ли с ней справится - посмотрим

anonymous
()
Ответ на: комментарий от Harliff

Гм.. дочитал до конца тред.

Если верить товарищу, написавшему, что reiser4 -- это не переделка reiser3.6, а совсем новый проект, где практически все сделано заново, то надо отдельно обсуждать эти две версии. А лучше -- забить на обсуждние 3.6 и говорить только о версии 4 (раз это две совсем разные ФС).

Если двадцать человек гоняют reiserfs на серваках/на слаке :)/на кривом железе/при дикой загрузке и при этом постоянно перезагружают комп и у них все хорошо, а у двадцать первого товарища reiser падает и губит кучу данных, то это значит, что reiser все еще нестабильна. Нужно спросить двадцать первого товарища, что он особеного делал, что она у него полетела (использовал какие-нибудь опции, по умолчанию не используемые, например).

Кто reiser4 использует (не 3.6, а именно 4)? Какие впечатления о скорости, надежности и функциональности?

Harliff ★★★★★
()
Ответ на: комментарий от Harliff

Использую reiserfs v3 уже года четыре (еще с 2.2 ядер) в качестве основной fs на серверах. Суммарный объем данных ~ 3ТБ. За все это время особых глюков (потерь данных) замечено не было. Нагрузка на fs ~ 5000 пользователей (nfs-root,домашние каталоги и т.д.), большинство файлов довольно мелкие. В ранних версиях были проблемы с KNFSD, приходилось использовать UNFSD. Так же были (и похоже остались - иногда warning'и лезут на консоль) мелкие проблемы с квотами при больщих нагрузках. Но глобальных проблем с потерей данных при испольозвании vanilla kernel и _стандартного_ gcc я не видел.

А вот если брать ядро от redhat и их gcc-2.96 (особенно в rh7.0 - rh7.2), то тут начинали появляться проблемы. Т.к. большинство пользовтелей не утруждают себя обычно прочтением FAQ на www.namesys.com и используют вышеупомянутые ядра и компилятор, то в результате получают развал fs и потерю данных. Глючность данной связки была проверена на личном опыте.

SVpcom
()

Почитать что тут уже понаписано, так можно подумать, что все на свете тем только и занимаются, что создают миллион файлов, а потом грохают его, и никаких других операций на сервере и не происходит. А у меня, пардон, там ещё и базы стоят, и упорно работают, и грош цена той ФС, которая под свои операции огромный кусок процессора отъедает, что Рейзер и демонстрирует, судя по всем НЕЗАВИСИМЫМ бенчмаркам. Так что нехай она на гденьть на файл-серверах живёт, а под базы мы уж как-нибудь JFS или XFS будем юзать. Подозреваю, что и владельцы Application-серверов меня поддержут, у них тоже процессорное время на вес золота.

bulch
()
Ответ на: комментарий от anonymous

HPFS была есть и будет и ей пофик все отключения питания работает медленно но уверено

anonymous
()

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

Значится по мотивам прочитанного: кому там квота была нужна - сузевые патчи на 2.4 работают, в 2.6 они уже в ядре. (это про reiser3 ясное дело)

Саныч: дык эта ж известная фишка с винтами которые при выключении не дозаписывают сектор, в результате при чтении - CRC error, лечится перезаписью сектора. А еще лучше - сменой бренда винтов или приобретением UPS ;)

Учитывая что reiser4 и правда целиком новый код - пассаж о "самой стабильной" fs в теле новости вызывает некоторые, хм, сомнения, так скажем. Но дальше будет видно. Easy to Audit это тоже смешно придумано.

green ★★★★★
()
Ответ на: комментарий от Harliff

жаль что ext3(2.4.24-pre2) не настолько стабильна она к сожалению падала. там файлики большие были и писались они друг за другом. падения были жуткими с потерей всех данных. на Reiserfs тоже было, но на ядрах до 2.4.16 там все засыпалось после неожиданного умерщвления сектора на диске (сектор видимо что-то важное держал), но, в отличии от ext3, фс удалось частично восстановить (конечно проявились всякие давно удалённые файлы, а содержимое многих не соотвествовало действительности) но сейчас reiserfs меня подводит только при потерях питания часто содержимое файла, открытого на запись, заменяется всякой фигнёй и иногда таким файлом становится системный конфиг ext3 использовать только с sync - тогда она точно не слетает да и остальные тоже не слетят

anonymous
()
Ответ на: комментарий от bulch

про "отъедание"

> и грош цена той ФС, которая под свои операции огромный кусок процессора отъедает

А что она, должна их производить с помощью Силы? Или пускай юзер подождет, как сами-знаете-где?

> а под базы мы уж как-нибудь JFS или XFS будем юзать

А зачем им вообще ФС, позвольте осведомиться?

Dselect ★★★
()
Ответ на: комментарий от SKYRiDER

> Ню-ню у меня UFS2(под FreeBSD) уже год на одном серваке вертится а >на ней и вебсервер с базой данных для форума и сквид и почта а офис >на территории цеха и стабильно от 2 раза в день рубят питание и >ничего, поднимается все на ура(fsck на фоне идет)

>Бздушка ты наша, я могу привести противоположный пример - у меня в >универе на серваке тоже стоит бздя :( на UFS2. Так вот она очень >часто (хотя и не всегда) никак не хочет подниматься после сбоя >питания.

вот что значит руки!!!
у кого UFS рушиться у того и ReiserFS не живет!

bsdushka
()
Ответ на: комментарий от green

Ну дык и я про тоже.

Только код успели написать и сразу кричать "самая стабильная", "самая

быстрая".

Скромнее надо быть, у людей фс по 10 лет в продакшн работают без единого

замечания, а тут "два года полет нормальный".

Sun-ch
()
Ответ на: комментарий от Unixphreak

> раньше там была ext3, hdparm выдавал 40 mb/sec, а щас пошустрее unixphreak

LOL

chucha ★★★☆
()
Ответ на: комментарий от Unixphreak

в биореактор... живо...

> ну так на hda на всех разделах новый рейзер раньше там была ext3, hdparm выдавал 40 mb/sec, а щас пошустрее

Ну не пользует hdparm ФС, не пользует!!

Dselect ★★★
()

Дабы прервать этот бесполезный треп, авторитетно заявляю следующее:

(1) reiser4 - это совершенно новый код. Там не то что кода с reiser3 нет, а я бы даже так сказал идей старых в неизменном виде не используется. Если кому интересно могу рассказать о внутренностях reiser4 или утилит.

(2) говорить о том что она супер стабильна и супер быстрая не то что рано, но как то стремно. В продакшне она не юзалась. Кто может это утверждать? Но то что reiserfs когда его включили в ядро был падучее в несколько раз точно. По сути стабилизация/оптимизация reiser4 продолжается больше года. Сейчас для десктопа пожалуй можно ее юзать (благо есть fsck). Думаю что через полгода можно будет ее юзать свободно для других применений тоже, так как:

- в ядро включили, будет пофиксено куча глюков.
- suse планирует ее заюзать. Chris Mason уже играется.

(3) есть правильные утилиты, правильный fsck уже сейчас. fsck v3 стало можно юзать только с год назад. Есть поддержка груба, gpart, etc. Легко можно добавить поддержку всем желающим, благо libreiser4 позволяет это сделать без проблем.

Banshee
()
Ответ на: комментарий от bsdushka

> вот что значит руки!!!

Блин, бздушка, если сервер не поднимается после отрубания питания, то причём здесь руки?

P.S. Я не админ того сервера. К счастью :)

> у кого UFS рушиться у того и ReiserFS не живет!

Блин, у меня дома почти 90 гектар (около 400 тысяч файлов) под ReiserFS 3 и ни единой проблемы за всё время эксплуатации.

SKYRiDER ★★★
()
Ответ на: комментарий от Banshee

> Дабы прервать этот бесполезный треп, авторитетно заявляю следующее...

Ну наконец-то хоть кто-то на пальцах разъяснил всё для тех кому лень почитать самим.

> Если кому интересно могу рассказать о внутренностях reiser4 или утилит.

Если не трудно, то расскажите. Очень интересно и думаю не только мне.

И ещё пара вопросов:

1. Сейчас Reiser4 включена в ветку Эндрю Мортона. Так? А когда можно ожидать включения в vanilla kernel? К 2.6.9 или позже?

2. Как Reiser4 переживёт вышеприведённый тест (создание/удаление кучи мелких файлов и нажатие reset в это время)? Думаю что благодаря атомарным операциям должно быть всё ОК, но как на самом деле? Сам пока проверить не могу.

SKYRiDER ★★★
()
Ответ на: комментарий от Banshee

>Если кому интересно могу рассказать о внутренностях reiser4 или утилит

Конечно интересно.

alman ★★★
()
Ответ на: комментарий от SKYRiDER

Что конкретно интересует? Куда не глянь всюду куча интересных моментов :) Например работа с деревом, или та же атомарность изменений.

Но пожалуй больше интрересует что-то конкретное что сразу же поможет в повседневных задачах. Вот есть такая херня как fibres. Это возможность групировки файлов и директориев внутри какого-то директория по определенному признаку. Например по окончанию или по длине окончания.

Например есть исходники ядра. Его нужно скомпилить.

Тела файлов лежат в дереве в соответствии с выбранным планом ключа. Их было несколько Plan A, Plan B, etc. Есть еще короткие ключи, длинные и так дальше. В общем по умолчанию тела файлов из одной директории лежат рядом друг с другом, а их стат даты лежат тоже рядом друг с другом, что дает возможность readahead-у работать более правильно.

В эту схемо можно внести небольшие исправления и добавить в один из компонентов ключа дополнительный признак групировки. Таким признаком является fibre. Он действует как угодно (это плугин) и иожет быть заменен другим фибром. Например можно написать свой. По сути этот плугин имеет одну функцию - сравнения.

Если использовать например fibre который всех групирует по окончанию *.c, тогда все файлы исходников будут лежать сгрупированными и компиляция пройдет заметно быстрее.

По поводу заданных вопросов. Ответы:

(1) Включили в ветку -mm. Одижать включения в ванилу можно когда угодно. Мы были свидетелями неоднократно как в ванилу включали вещи которые по идее еще не сильно готовы для продакшн. Reiser4 не самый плохой кандидат. По сути технических проблем не так много. Больше бюрократических мне так кажется.

(2) Он перенесет это издевательство легко. Иначе его бы не зарелизили.
Вообще проблемы у него в данный момент несколько другого плана. Не столь примитивные. Различные оптимизации типа COC (copy-on-capture), нужно уменьшить потреблене стека, и так дальше.

Banshee
()
Ответ на: комментарий от Banshee

Вернее главная задача fibre-plugin это формировать fibration component который используется при создании ключа.

Banshee
()
Ответ на: комментарий от SKYRiDER

>> Слушьте, а там конвертировать сущетсвующий раздел с reiser v3 -> reiser v4 можно будет?

>> Нет. Только tar'ом. Хотя если ты им заплатишь денюжку, то они для тебя напишут конвертор.

А если я им заплачу --- они мне другой напишут?

anonymous
()
Ответ на: комментарий от Unixphreak

учимся пользовать google

> ну а как тогда затестить reiserfs?

http://www.iozone.org/

А вообще-то, STFW, keywords: filesystem benchmark Linux

Dselect ★★★
()
Ответ на: комментарий от anonymous

Вот такого:

> содержимое файла, открытого на запись, заменяется всякой фигнёй

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от Deleted

По умолчанию bash используеть встоенный rm, у которого таки имеется ограничение на список аргументов. А если попробовать /bin/rm ./*.jpg ?

anonymous
()
Ответ на: комментарий от anonymous

> А если попробовать /bin/rm ./*.jpg ?

Ответь на вопрос, кто будет раскрывать звездочку: шелл или rm, и как это вяжется с ограничением на длину коммандной строки?

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

плохой, негодный админ

> в нормальной fs быть не должно.

Ага, сейчас снова пойдут сказки о журналировании данных :)

> А если есть, то это плохая, никуда не годная fs,

А что, хорошая ФС может спросить у Мирового Разума, что было в блочном кеше в момент "Ч"?

> тем более, если > > иногда таким файлом становится системный конфиг

Нефиг все на один раздел запихивать.

Dselect ★★★
()

была у меня однажды "битая" память.

и работал райзерфс - при отключении питания, иных сбоях - происходило что-то страшное, папка lost+found наполнялась всяким мусором :-)

а потом я попробовал xfs и даже с битой памятью все было нормально (при подобных происшествиях делал проверку - все востанавливалось)

вот... а на одном знакомом провайдероском сервере (не скажу, что нагрузка большая, но что-то есть: фтп (огромная файлопомойка), почта, апачи) пользователей этого всего в районе 300-400. стоит райзерфс года два уже и все там у них хорошо.

но xfs поразила способностью работать с нехорошим железом :-)

o1o
()
Ответ на: плохой, негодный админ от Dselect

> Ага, сейчас снова пойдут сказки о журналировании данных :)

Нет, "сказки" пойдут про атомарные операции. В UFS непротиворечивость FS обеспечивается софтапдейтами и снепшотами, гарантируя, что единственная возможная неприятность - "лишние" занятые иноды, что легко и быстро правится в фоне fsck на рабочей (rw) fs. В линукс теперь появилась ReiserFS4. Без всякого журналирования данных в чистом виде.

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

> Нефиг все на один раздел запихивать.

Это не ко мне, я цитировал.

baka-kun ★★★★★
()

Основной спонсор проекта - DARPA. Поэтому, все эти "military grade" - не пустой треп.

anonymous
()
Ответ на: комментарий от baka-kun

> А если попробовать /bin/rm ./*.jpg ?

>Ответь на вопрос, кто будет раскрывать звездочку: шелл или rm, и как это вяжется с ограничением на длину коммандной строки?

Ага, звыняйте, сглупил. Просто наткнулся раньше на такую фигню (и даже не в bash, а в tchs на Фре) где прошел /bin/rm.

anonymous
()
Ответ на: комментарий от baka-kun

ФС или БД?

> Нет, "сказки" пойдут про атомарные операции. В UFS непротиворечивость FS обеспечивается софтапдейтами и снепшотами гарантируя, что единственная возможная неприятность - "лишние" занятые иноды

Да? А противоречивость _данных с точки зрения приложения, их использующего_ ? Ах, да, это не неприятность, это 3.1415926здец :)

P.S.

Атомарные операции -- это хорошо, конечно, но как userspace софтине сказать ФС "данные в файле blah в данный момент непротиворечивы"?

Dselect ★★★
()
Ответ на: ФС или БД? от Dselect

> Да? А противоречивость _данных с точки зрения приложения, их использующего_ ? Ах, да, это не неприятность, это 3.1415926здец :)

У тебя логическая ошибка: ты распространил проблему асинхронной журналируемой ФС на все прочие. Конечно будет мусор, если метаданные уже записались (или накатился журнал), а данные потеряли.

Мусор в файлах -- это проблема асинхронных ФС. FFS с SoftUpdates (FFS-SU) решает ее (одновременно с обеспечением непротиворечивости) ослеживая зависимости метаданных, еще и группируя их для уменьшения операций записи на диск. Reiser4 делает это по своему, но очень похоже. Метаданные для файла или обновятся целиком, или нет.

FFS-SU полность асинхронна в том смысле, что сисколл возвращает результат не дожидаясь записи данных на носитель, но:

1. метаданные будут записаны только после обновления битмапа и данных,

2. отслеживаются зависимости метаданных -- сначало обновить bitmap, записать данные, обновить inode, затем directory и т.д.

Поэтому, если не успели обновиться метаданные, содержимое файла не поменяется. Я ведь говорю, единственное, что может произойти -- некоторые блоки в битмап помечены как занятые, но никто на них не ссылается. А это легко лечится в фоне, поскольку влияет только на оставшееся свободное место. Нет, вру. Еще одна ситуация возможна -- сбой на середине mv. Тогда просто на файл будет две ссылки, но ФС останется непротиворечивой, и никакие данные не потеряются.

> Атомарные операции -- это хорошо, конечно, но как userspace софтине сказать ФС "данные в файле blah в данный момент непротиворечивы"?

С действительно атомарными операциями, как и с UFS-SU, такого не происходит. Надо мне еще почитать, как Reiser4 борется с увеличением ссылок на файлы при обломе mv.

baka-kun ★★★★★
()
Ответ на: комментарий от anonymous

>>Создай пару-тройку десятков тысяч файликов небольшого объема, а потом >>удали их все...
У меня на серваке каждый день создается порядка 30 тысяч файлов, далее ночью все они запаковываются в архив и удаляются. Работает все это порядка года. ReiserFS 3. Что я делаю не так ?
Мой опыт говорит о том что оно вполне стабильно.

anonymous
()

davinchi

Товарищи, не стоит забывать, что любая ФС зависит от многих вещей - ЖД, версии, версии утилит и так далее,

у меня на ALTLinux 2.2 Master Reiserfs 3.6 уже полтора года, при этом я раз-два в день вырубаю :)

anonymous
()
Ответ на: комментарий от Unixphreak

Хахаха странное дело, господа у меня очень похожие данные -- 168 метров за 3.03 секунды, но..это равняется 55.42 Мб/сек какой-то бред, не правда ли? толи у него секунды менее вместительные, толи мегабайты более объемные....ж-)))

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.