Представлены (http://www.phoronix.com/scan.php?page=article&item=reiser4_b...) результаты сравнения производительности файловых систем Reiser4, ReiserFS 3, EXT4 и Btrfs. В качестве Linux ядра использовано модифицированное ядро от проекта Zen Kernel (http://www.zen-kernel.org/) (2.6.33-rc7-zen1), отличающееся интеграцией последней версии патчей с поддержкой Reiser4 (http://reiser4.wiki.kernel.org/).
В тесте SQLite ФС Reiser4 примерно в два раза отстала от ReiserFS 3 и EXT4. В первой фазе выполнения теста Compile Bench ситуация сложилась противоположным образом, Reiser4 обогнал EXT4 примерно на 60% и оказался быстрее ReiserFS 3 в 6 раз. При выполнении компиляции в тексте Compile Bench производительность Reiser4 оказалась примерно равна EXT4, отставание ReiserFS 3 сократилось до двух раз, а в качестве лидера выступила файловая система Btrfs, обогнавшая Reiser4 и EXT4 на 25%. В операции чтения собранного дерева исходных текстов в тесте Compile Bench файловая систем Reiser4...URL: http://www.phoronix.com/scan.php?page=article&item=reiser4_b...
Новость: https://www.opennet.ru/opennews/art.shtml?num=25653
>В итоге Reiser4 одержал победу в 5 из 7 тестов.Кто бы сомневался.
//Довольный пользователь r4 с конца 2008 года
BTRFS//Довольный пользователь reiser4, до того как попробовал XFS и BTRFS
уже дарпа его давно не финансирует, автора упекли в тюрягу. интересно, что ещё должно произойти, чтобы упрямые сопляки-ламеры перестали носица с этой мегасуперэфэс? даже если опустить обсирание её технических недостатков, очень часто приводящих к невосстановимой потере данных (с чем столкнулся лично на корпоративном сервере, который оставил после себя один такой супер-мега-компьютерщик, даже не обеспечив толком бэкапа), неужели нельзя понять, что "выжимание" микросекунд базируется на технологии, которая скоро просто исчезнет! оптимизация движения магнитных головок через пару-другую лет вообще перестанет быть необходимостью, потому что "граммофоны" можно будет найти только в суперкомпьютерных центрах, где они просуществуют ещё максимум десяток лет. это чисто популистский проджект бездарного ламмера, запутанная как катушка ниток куча убогого кода.хватит уже о трупах
Не бойтесь, господин теоретик. Бизнесхрены с флешом вам устроят очень много интересных сюрпризов, которые станут вам икаться лишь через несколько годков. У флеша зиллион своих проблем. Флеш известен с 80-х годов. А что-то хоть немного потребное по параметрам осилили только через 25 лет. И то - с массой особенностей и западлянок, о которых барыги продающие "новое, модное и крутое" разумеется не любят говорить. При том подляны касаются сохранности данных в основном. Проблемы можно было бы решить поюзав иные технологии, но никому не хочется ждать еще 25 лет. Бабло всем хочется рубать сейчас. Поэтому будете жрать сыпучий, склерозный и протирающийся флеш как миленькие. И это булдет "модно, круто и современно". А вот сможете ли вы прочитать хоть чего-то через 10 лет с такого накопителя - баааааальшой такой вопрос.
У флэш памяти действительно бешенные проблемы с сохранностью данных. Т.к. при гибели подложки или самого кристала мс (зачастую по вине цепей основного питания) информация безвозвратно утеряна. И вы хоть головой потолок пробейте, но восстановить вам ее не удастся. В случае с магнитными накопителями, полная гибель самого хранилища информации не возможна (точнее очень низкий процент), в основном выходят из строя цепи управления и передачи данных, что не мешает перенести "блины" на другое рабочее тело. Если даже использовать системы резервирования, то объем, для доведения флэш накопителей до необходимого уровня безопасности хранимой информации, потребуется в 4 раза больший, чем при использовании магнитных накопителей, причем потребутся диверсифицировать цепи питания. Ибо процент отказа на доступ у кристалов все еще очень высок, и зависимости по питанию никто не отменял, а лепить кучу интергальных стабилизаторов на цепи питания бессмысленно. Недостатком hdd является, безусловно, уязвимость при резких механических воздействиях, но это никак не связано с перифейрыми модулями и устройствами, как в случае с флэш.
> У флэш памяти действительно бешенные проблемы с сохранностью данных.
> В случае с магнитными накопителями, полная гибель самого хранилища информации не возможна (точнее очень низкий процент),Вы открыли нам глаза! А я всё удивлялся, почему запретили релейные компьютеры и перевели всю вычислительную базу сначала на электронные лампы, потом на транзисторы, под конец на интегральную электронику. Оказывается, рэле — самый надёжный переключатель из всех когда-либо изобретённых переключателей, потому что там электромагнит с коромыслом, замыкающем контактные пары, там нечему ломаться! :))
а для торентов кто быстрее ? :)
>а для торентов кто быстрее ? :)XFS? :)
корбина?
Пентиум IV и десятимегабитная сетевая карта.
Тот, у кого random seek/read быстрее - Raiser4 соответственно.
Там актуальна шустрая работа с большими файлами и стойкость к фрагментации. Сталбыть XFS скорее всего. Кстати надо ж так Reiser'а обозвать - Raiser :)
>а для торентов кто быстрее ? :)FAT16 на SSD :)
Мсье знает толк в извращениях. Только вот фат 16 катит для очень мелких торентов на очень мелких дисках, при этом смысл в торентах становится не очевиден :)
Для компиляции надо использовать tmpfs, она порвет любую фс как тузик грелку.
+1
подтверждаю :)
Только предварительно пару раз всё завесит при хорошей нагрузке.
все не завесит: для "alt"+"SysRq"+"k" всегда найдутся ресурсы =).
Не подтверждаю.Для компиляции не важна скорость записи на ФС, а важна частота процессора и распараллеливание.
ФС в памяти и ФС на диске для компилятора практически идентичны по свойствам.
>Не подтверждаю.
>
>Для компиляции не важна скорость записи на ФС, а важна частота процессора
>и распараллеливание.
>
>ФС в памяти и ФС на диске для компилятора практически идентичны по
>свойствам.При мощном камне и больших мозга узким местом при компиляции большого объема сорцов будет как раз скорость доступа к файлам
Поддерживаю Reiser4.
Давно известно, что ReiserFS быстра при работе с тучей мелких файлов, так как хранит их в inode-ах.
Это нечестно?
Может таки reiser4 включат в основное ядро?А то пока для файлопомойки под названием /home быстрее чем reiserfs ничего нет.
а почему с ntfs не сравнили?
Потому что ntfs проприетарная, POSIX-несовместимая поделка с закрытым исходником, из-а чего и не имеет нативной поддержки в ядре.//Ваш К.О.
Дорогой К.О., в linux ядре есть драйвер NTFS, работающий в режиме только для чтения. Содержится он там с 2.2 ядра. Лицензия, естественно, GPL.А почему ntfs-3g не внутри ядра - так скорее всего из-за древнекитайского философского вопроса - "а на хуа?".
дорогой не К.О.
> "а почему с ntfs не сравнили?"
> драйвер NTFS, работающий в режиме только для чтения.тебе не кажется что ты сaм ответил на свой вопрос ?
> А почему ntfs-3g не внутри ядра - так скорее всего из-за древнекитайского философского вопроса - "а на хуа?".
прочитай и этот свой комментарий и может поймешь что ты просто не знаешь почему.
> тебе не кажется что ты сaм ответил на свой вопрос ?Это не я задал вопрос "почему с ntfs не сравнили?". :-)
> ...в linux ядре есть драйвер NTFS, работающий в режиме только для чтения...попробуй "$ mount -o rw ..." и удивись :-)
>попробуй "$ mount -o rw ..." и удивись :-)Это наверняка ntfs-3g. В Linux есть 3 разных, но родственный драйвера NTFS:
1) Драйвер, включённый в ядро. Работает в режиме RO, последняя версия драйвера написана в рамках проекта Linux-ntfs. Умеет, правда, перезаписывать файлы (rw режим), в этом смысле команда mount -o rw сработает. Но создавать новые каталоги, файлы он, по-моему, не может (я давно не проверял).
2) Драйвер fuse, написанный в рамках Linux-ntfs, работает в режиме RW. Это более-менее полная реализация записи.
3) Драйвер fuse, написанный в рамках ntfs-3g, режим RW (аналогично, более-менее полная реализация записи). Это форк Linux-ntfs, получивший возможность записи раньше Linux-ntfs.
стеснительный производитель забашлял коррумпированному форониксу, чтобы _не_? $)
>а почему с ntfs не сравнили?За очевидностью. FUSE всё просадит так, что какие-либо количественные сравнения с NTFS-3G на той же системе станут бессмысленными. А сравнивать с производительностью Windows/NTFS как-то странно - там совершенно другая ОС.
>А сравнивать с производительностью Windows/NTFS как-то странно - там совершенно другая ОС.Ну ка с этого места поподробнее.
То есть если на том же железе другая ОС пройдет тот же тест намного быстрее это ничего не значит ?
Капитан очевидность считает, что в этом случае одна OC намного лучше другой, разве нет?
Очевидно капитан не понимает, что сравнивают различные ФС, а не ОС. Причём стараются это делать при прочих равных условиях. Тогда надо либо NTFS под Линухом (но она там во FUSE, что, опять же, не равные условия), либо Reiser4 под Виндой (чего очевидно в природе не существует).
>либо Reiser4 под Виндой (чего очевидно в природе не существует).http://www.p-nand-q.com/download/rfstool.html
>>либо Reiser4 под Виндой (чего очевидно в природе не существует).
>
>http://www.p-nand-q.com/download/rfstool.htmlЭто, извините, ReiserFS, которая 3. Плюс ещё две маленьких поправочки:
* Access is read-only. I do not intend to change that, at least for the time being.
* Journal data is ignored. These tools show the file structure as it is ON DISK, right now.Кроме того, это не драйвер, а пара утилит. Т.е. даже с ntfs-3g не сравнить.
>>>либо Reiser4 под Виндой (чего очевидно в природе не существует).
>>
>>http://www.p-nand-q.com/download/rfstool.html
>Это, извините, ReiserFS, которая 3. Плюс ещё две маленьких поправочки:
>Кроме того, это не драйвер, а пара утилит. Т.е. даже с ntfs-3g
>не сравнить.Согласно учению Вернадского (тот который проспект),
- Если что-то, кому-нибудь нужно, то оно обязательно появится.
"Учитывая увеличивающуюся индустриализацию общества, скорость
транспорта, возможности радиосвязи, влекут за собой взаимодействие
людей различных интересов, знаний и культур. Итогом этого взимодействия
станет равномерность распределение ноосферы. Отсутствие какого-либо
знания в одной области ноосферы, влечёт её скорейшее заполнение.
Такие области будут возникать, в тех местах где общество дошло
до той стадии развития, когда необходимость в них возникла.
Не исключается одновременное, в тоже время независимое проявление
сей потребности."
А для тех кто родился после 1991,
- Если б яблоко упало не на Ньютона, то завтра оно бы упало на Ломоносова.
для тех кто родилсяпосле 1991 -- объяснение короче! o_0какбы нечесно! они что -- умнее нас? (а для "нас" -- разжёвывание было на 9 строчек!)
>для тех кто родилсяпосле 1991 -- объяснение короче! o_0
>
>какбы нечесно! они что -- умнее нас? (а для "нас" -- разжёвывание
>было на 9 строчек!)Сарказм засчитан)
> То есть если на том же железе другая ОС пройдет тот же тест намного быстрее это ничего не значит ?Ну, всё что-нибудь да значит.
> Капитан очевидность считает, что в этом случае одна OC намного лучше другой, разве нет?
Капитан очевидность считает, что есть дохрена факторов при выборе ОС, значительно более важных, чем быстродействие ФС. Хотя бы потому, что иначе бы неглупые люди в фирме Микрософт хоть как-то ускорили NTFS под Windows за прошедшие 10 лет.
>а почему с ntfs не сравнили?/me сомневается что NTFS что-то светит. Зайдите в диру с 50 000 файлов - и вы сами ощутите все прелести NTFS :)
>/me сомневается что NTFS что-то светит. Зайдите в диру с 50 000
>файлов - и вы сами ощутите все прелести NTFS :)Это, друг мой, какой драйвер/ОС?:
1) Win
2) Lin/Fuse/NTFS-3G
3) Lin/Fuse/LinuxNTFS
4) Lin/Ядерный драйвер?Говорят, NTFS-3G есть даже под WinCE ;-)
Да в принципе - какая хотите и какая вам удобнее. NTFS-3G сам по себе тормоз по понятным причинам, имя которым FUSE. Я им пользовался. Проц грузился, скорость была не фонтан. Перешел на том же томе на XFS - мягко говоря, "почувствуйте разницу". И скорость лучше и проц грузит намного меньше. Вторая жизнь того же диска! ;)Ядерный драйвер насколько я помню сроду недоделанный, без полноценной надежной записи. А на описанный эффект можно поглазеть и в виндозе просто создав 50К файлов в 1 папке. И потом попробовав туда сунуться. Если не повезло - чтение такой диры "на холодную" (т.е. без срабатывания дисковых кешей, когда дира читается с диска в первый раз) - занимает до десятков минут, система при этом сурово тормозит. Да и с большими файлами типа торентов нтфс работает не очень. И фрагментации очень подвержен. А когда после некоторой заполнености тома начинает фрагментироваться MFT - там вообще сушите весла. Тормозилово начинается адское. Вообще NTFS по субъективным впечатлениям не производит ощущения быстрой ФС. А вот XFS на больших файлах реально так шпарит по сравнению с многими другими. И сопротивляется фрагментации хорошо.
>/me сомневается что NTFS что-то светит. Зайдите в диру с 50 000
>файлов - и вы сами ощутите все прелести NTFS :)зайди это ~имеется~ввиду~ "$ ls" ?
когда я делаю ls при одновременном скачивании торрента, то операция ls занимает 0.5~1.0 секунды, даже когда на этом ntfs в дирректории только пару файлов x_x
>0.5~1.0 секунды, даже когда на этом ntfs в дирректории только пару
>файлов x_xА чтение списка 50К файлов "на холодную" озадачивает винду минут на 10-15. В течение которых все жутко тормозит. Под линухом данный эксперимент с нтфс честно говоря не пробовал, но подозреваю что там врядли сильно лучше (а может и хуже если вспомнить о FUSE). В винде данный эксперимент провел совершенно случайно в общем то. Совершенно случайно зашел в диру где как оказалось валялось 50К файлов. Очень удивился когда все стало раком на 15 минут. В одном я уверен: современные ФС *так* работать не должны!
12309?
>а почему с ntfs не сравнили?Сравниваются современные ФС.
[ НАГРУЗКА НА CPU ]BTRFS против XFS - http://pavlinux.ru/fs/XFSvsBTRFS.gif
BTRFS против XFS против NTFS-3G - http://pavlinux.ru/fs/BTRvsXvsNT.gif
linux-2.6.33-libre :)
4Gb DDR PC3200 ECC
2 x 285 Opteron
HDD: Western Digital WD7500AAKS-00RBA0# cat /proc/mount
/dev/sdc1 /media/vm btrfs rw,relatime,compress,noacl 0 0
/dev/sdc2 /media/disk xfs rw,noatime,nodiratime,noalign,inode64,logbsize=256k,noquota 0 0
/dev/sdb3 /media/dvd fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=2048 0 0# iozone -a -b OUT.xls -+u -p -B -e -E
ААА, графики анимированные!P.S.
Я вижу, вам вкатила libre?)
>P.S.
>Я вижу, вам вкатила libre?)Если честно, то снизилось обращение к диску,
оофис как-то подозрительно быстро запускается.Точнее, всё было на оборот.
Смеркалось. За окном, слышны звуки капели, напоминающие о
приближающейся весне. Луна застряла в макушках деревьев.
Одинокий ветерок проносится мимо спящего города, тихий лай
собаки чуть слышон долече.
Работаю. Обычно, ночью запускаются всякие служебные скрипты, freshcalm,
Yast online update, rpm --rebuilddb, маны пакуются и прочая хрень.
Ну так вот, сижу, работаю, диск вообще не шуршит, один раз обратил на это
внимание, второй раз, третий, на четвёртый поползли мурашки и холодный пот...
Думаю, "- Пипец, доигрался, работаю на кэше и RAMe".
Ну-кась, надо пингануть диск - dd if=/dev/zero of=BIGFILE, фу, зашуршал, Ctrl-C
На всякий случай, контрольный ребут, потом опять фаерфокс, gimp, оowriter.
Ёпс, ёпс, ёпс, за секунду открылись.... :-/ Чё за нах?!?!?
Вспоминаю, че делал!? Вроде в систему не лазил, остаются только ядры.
А перепробовал я вчерась аж три ядра - git последний, -ck и -libre ...
Ну я бегом uname -r, а оно мне - 2.6.33-libre.
Вот такие страсти. Теперь боюсь испортить... :)К этой теме ни какого отношения не имеет, ещё вчерась хотел написать, но лень уже было...
Значит не врут истории про то, что если из Win выкинуть левый код, она запустится даже на 386 =)
А вообще любопытно.
Как уладятся траблы ndiswrapper и 33 ядра, можно будет попробовать.
>/dev/sdc1 /media/vm btrfs rw,relatime,compress,noacl 0 0Ну то есть по графикам btrfs всех рвет, включая xfs. потому что даже с прозрачным gzip сжатием она офигенна.
>>/dev/sdc1 /media/vm btrfs rw,relatime,compress,noacl 0 0
>
>Ну то есть по графикам btrfs всех рвет, включая xfs. потому что
>даже с прозрачным gzip сжатием она офигенна.Ага, офигенна, BTRFS процессор жрет на 60%, в то время как XFS всего 20% :)
про NTFS-3G вообще молчу ...
Это графики - Использования процессора при операции записи.
