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 ()

Пока только core стабильна, а все фичи или альфа или вообще не сделаны.

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

> эт точно, как рухнет, так и пы$дэц. она шустро бегает, но не долго, а спотыкается ой как часто

Анонимус, пи$деть не надо. Ты Reiser4 хоть видел?

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

> Кстати, код Reiser4 был включён в ядро 2.6.8.1-mm2

А ее лицензия не против? Я краем уха слышал, что в дебиановской рассылке что-то говорили нехорошее...

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

про лицензии.

> А ее лицензия не против? Я краем уха слышал, что в дебиановской рассылке что-то говорили нехорошее...

Говорили про mkreiserfs, а не про "ядерный" код.

Dselect ★★★
()

Кто-нибудь уже использовал, как впечатления ?

anonymous
()

На моих слаках Reiser работает 2 года без всяких багов, где предидущие ораторы их нашли не понимаю...

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

А твои слаки вообще работали? Или серваки лежали в коробках на полках? Хочешь для своей райзер тест? Создай пару-тройку десятков тысяч файликов небольшого объема, а потом удали их все... Backup данных с винта перед экспериментом делать воспрещается :)

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

Недавно проверял с выключением питания... Иногда всё фиксится без потерь данных, а иногда некоторые файлы в lost+found кидаются.
reiserfs (v3)

В reiser4 такая фича есть, как atomic fs: файловые операции или происходят, или нет. Нет потерь данных при половинчатой операции, т.к. таковые не происходят.

Идея отличная и инновационная. Пожелаем удачи тем, кто living on cutting edge :)

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

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

под какой fs ?

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

>ReiserFS?

и чё должно быть ??

Это стандартный тест, в котором райзер стабильно бъёт остальные линуховые fs

мб ты о NTFS думал ??

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

>рейзер сдохнет

ладно врать-то

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

Сколько ни юзаю райзер - не падает. У меня только на рабочем компе за 2 года явно больше 10000 операций по созданию/удалению файлов было - работает. И где же мне глюки в райзере найти - хз.

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

Это что за бредовый тест? Разве может нормальная файловая система от такого теста ршиться или даже глючить?

P.S. Кстати, я проверил на loop-устройсте. До сих пор живой. Что я делаю не так?.. А! До меня дошло! У меня не слака и не сервер :-)

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

>Это что за бредовый тест? Разве может нормальная файловая система от такого теста ршиться или даже глючить?

Говорят, что NTFS от этого падала - там таблица файлов разрасталсь на почти весь диск, а уменьшать они её не умели, но может быть уже исправили

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

и не планируется такая поддержка?

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

Идиет ;)
У нас сейчас один из самых крупных в рунете проектов (если уже не самый крупный :D Траффик идет уже на десятки терабайт) - там на десятках серверов reiserfs крутится - с количеством файлов сотни тысяч (если не миллионы - не считал особо :) )
Траблов с ФС никогда не было
Было по резету невовремя что надо было fsck сделать - это все что случалось
Потерь данных - никогда...
Ох уж эти пЫонерЫ :D

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

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

bsdushka
()

Пару лет назад при написании одного проекта я пихал кучу картинок в одну директорию. Сегодня я обнаружил там более 47 тыс. картинок... До сегодняшнего дня даже и не задумывался об этом, благодаря ReiserFS. А вот удалять их -- не так просто, потому что bash ругается на слишком длинный список аргументов :) Приходится прибегать к find -exec, а это действительно долго.

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

vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640908 1640914 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45609280
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640908 1640963 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45610896
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640908 1640912 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45610896
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640908 1640910 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45609280
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640908 1641433 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45610896
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640905 1990020 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45610896
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640905 1990028 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45610896
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640905 1990033 0x0 SD]
end_request: I/O error, dev 03:02 (hda), sector 45610896
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1640905 1990041 0x0 SD]

Йопс!!

Чё то мне кажется, что я щас огребу :(

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

Sun-ch, как ребенок, право слово!

Пока работает -- НЕ ТРОЖЬ!

P.S. Не забудь потом проверить валидность контента инодов и на запорченное навесить заглушки. :)

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

> А твои слаки вообще работали? Или серваки лежали в коробках на полках?

спать б*я! у меня на 8.1 шлаке на райзере с 10-м софтовым раидом и по-ныне Оракл живет и не париться... и нех%й гнать на шлаку

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

Довожу до вашего сведения, что у меня в течении полугода сервачок файловый ежедневно выключался вырубанием питания, а на следующие утро всё прекрасно работало и там стоял Reiser.

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

> Идея отличная и инновационная.

Этой идее уже сто лет в обед :)

---

> крутится - с количеством файлов сотни тысяч (если не миллионы - не считал особо :) )

Хорошо округлил :)

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

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

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

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

> Довожу до вашего сведения, что у меня в течении полугода сервачок файловый ежедневно выключался вырубанием питания, а на следующие утро всё прекрасно работало и там стоял Reiser

Девочка в каске гуляла по стройке, на нее упал кирпич, она улыбнулась и пошла дальше.

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

файлов - 422221

общий размер - 13.1 Gb

Создал, удалил, жесткий ребут - фсе живое и работает

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

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

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

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

>Если питание на ходу вырубать, то любая FS подохнет.

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

В общем, надёжнее NTFS нет пока ничего :)

А под Linux - что Reiser, что ext3 - сбои случаются чуть ли не на каждом втором отрубании питания.

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

>Так вот она очень часто (хотя и не всегда) никак не хочет

Не умеешь уговаривать - лутше не суйся к девушке.

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

> Я знаю эту дефочку, она там и сейчас ище ходит.

... улыбается, и раздает прохожим диски с кноппиксом ;)

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

Мужики, я рад что вы знакомы с такими клёвыми девчёнками, возможно в будущем вы встретите кого-нибудь получше :),но факт отсаётся фактом Reiser стабильно работал даже на первом пне без APMа, и возможности вырубить нормально питалово.

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


>NTFS на переносных винтах такое переживала раз двадцать :) Т.е. >именно вырубание питания винта без предварительного >размонтирования. Ну и десятки раз просто свет дома отрубали. Или >верх экстрима - когда однажды, забыв отмонтировать, подрубил по >?>горячему вместо одного винта другой. И системная область новая >прописалась, да и иная геометрия сказалась. В общем, поимел >совершенно нечитабельный диск. Один проход chkdsk - и только >несколько утерянных файлов (из тех, что писал уже после этого >сбоя).
>
>В общем, надёжнее NTFS нет пока ничего :)

Мда? А у меня было наоборот...после 2х сбоев питания NTFS отказалась восстанавливаца...данных 1/3 всего спасти смог и грузица не хотела...пришлось полностью винтик форматировать.
После на этом же жестяке (это чтобы не гнали на кривое железо) стояла ext3 (ныне reiser)...и ниодного сбоя. Нифига не потерял.

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

про длинные списки

> А вот удалять их -- не так просто, потому что bash ругается на слишком длинный список аргументов :) 

А rm -rf -- некошерно, да? 

В крайнем случае,

#!/bin/sh 

DIR=$1
# extra options to find
CRIT="" 

if [ "x${MAXARGS}" == "x" ]; then 
	MAXARGS=1000
fi

# what should we do with those files?
if [ "x${CMD}" == "x" ]; then
	CMD="ls -l"
fi

if [ ! -d "${DIR}" ]; then 
  exit 0
fi

cd ${DIR}

eval $(find . ${CRIT} -type f | sed -n -e "
# insert linebreak after MAXARGS lines
1~${MAXARGS} bn
# append line to hold space
H
# start new cycle
d

:n
i${CMD}

# process everything we collected so far
x

# replace newline character with space
y/\n/\ / 
# finally, print command
p
i\
;
")

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