LINUX.ORG.RU

Анализ современных журналируемых файловых систем для Linux


0

0

В статье по ссылке дан грамотный сравнительный анализ устройства и производительности современных файловых систем: Ext3 vs JFS vs ReiserFS(v3) vs XFS, а также их сравнение с Ext2 и FAT32 -- хорошее пособие для выбора файловой системы под ваши конкретные задачи.

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



Проверено:

Re: Анализ современных журналируемых файловых систем для Linux

А NTFS, NTFS5, NTFS5.1 с ЕХТ2 боятся сравнивать???
Накой сравнивать ЕХТ2 с ФАТ32, когда это уже делали очень много раз?
Каждая из этих файловых систем (Винды9х и Линуха) предназначена для разных задач. У ФАТ32 (а особенно у ФАТ16) есть неоспоримое преимущество обратной совместимости с ранними версиями. И это людьми ценится. Конечно, ФАТ не лучшая ФС для винта, но её преимущество - повсемесная поддержка и небольшая нагрузка оперативной памяти. Кстати, после полной дефрагментации, ФАТ32 бывает даже быстрей ЕХТ2 :-)

Журналируемость - вещь хорошая, но для домашнего компа совсем не нужная (в ХР я её отключил). Для сервака бывает полезна, правда в такой кривой реализации ЕХТ3 это неинтересно...

Кроме того, кроме NTFS5 и ФАТ16 (хотя в реализации DriveSpace плоховато получилось) я нигде не видел возможности сжатия данных на диске, а она иногда очень полезна при хранении на винте большого количеста текстовых файлов.

Для полноты флейма, можно заметить что UFS быстрее ЕХТ2 (и тем более ЕХТ3)..

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

2anonymous

Полный бред. Зачем отключать журнал? Ради 2% повышения скорости?

Вообще-то считается что ext3 быстрее ext2, да и вообще ext3 одна из
самых быстрых FS.  Кстати лично Вам она должна была понравиться из-за
совместимости с ext2 ;-)

Вот с кодированием (шифрование, упаковка, ...) на уровне отдельного
файла/каталога это верно подмечено.  Насколько я знаю в linux'е так
никакая FS не может (и не планирует).

С уважением,
Ukos

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Мыжик наверное большой знаток файловых систем

Banshee ()

Re: Анализ современных журналируемых файловых систем для Linux

Есть такой патчик к ядрам, кажется от 2.2.12 до 2.2.17, называется, вроде, e2compr... Кароче позволяет сжимать файлы, у ext2 есть для этого специальный бит, указывающий что файл сжат. Там 2 алгоритма - gzip и еще какой-то... Сжимается и разжимается все это посредством установки этого бита: chattr -R +c /dir_name (для каталога) или chattr +c file_name (для отдельного файла), в общем вроде NTFS получается :) Весчь очень удобная... Я им пользовался пока не переехал на 2.2.19 Никаких траблов вроде небыло, плохо только что такая ФС не читается непатченным ядром.К сожалению, как я понял, автор давно забил на этот проект. Жаль...

anonymous ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

NTFS, говоришь, лучше ... У меня естьтут такой косвенный тест. Он относится кстати не только к файловым системам, а вообще (но от винта там многое зависит). Вобщем в эксперименте принимали участие:

1. Сервер Samba (800 МГц целерон, 128М ОЗУ, винт SeaGate (вобщем на всех машинах одни и те же винты))

2. Клиент Вин 2000 ВС (всё то же самое, но ОЗУ 256М)

3. Клиент МД98 (железо как в п. 2).

Далее: как известно, сеть 100 М/бит быстрее чем IDE винт в реальных условиях (так было раньше да и сейчас это почти везде актуально).
Берём значит и копируем с Самбы на МД2000 -- получаем почти 8 мегабайт/сек, копируем с МД2000 на Самбу -- получаем почти 6 мегабайт/сек, копируем с МД98 на Самбу -- получаем что-то около всего 2,5 мегабайт/ сек. Копировался фильм целиком (>600 Мег)

И что имеем (взгляд масдайца): какой-то глючный Линукс с недоделанной Самбой и недоделанной EXT3 тем более обделённый памятью отдаёт файлы на 30 процентов быстрее чем классная и потрясная МД2000 ??? Да не может быть !!! :-)))))))

И что имеем (взгляд Линуксоида): всё именно так как и должно быть, а что будет если Самбе добавить ещё 128М ??? :-)))

P.S. может я нарушил чистотут эксперимнта ??? Но всё железо одинаковое (до сетевых карт включительно), кстати, сетевое железо дешёвое :-) RTL8139 (правда не елайн ине аккорп, не помню какое) хаб -- нетжир :-)

Warmonger ()

Re: Анализ современных журналируемых файловых систем для Linux

Вообще-то из твоих тестов следует, что если Самба выступает в качестве приемной стороны, то она плохо работает. Т.е. она действительно какая-то не до деланная.

anonymous ()

Re: Re: Re: Анализ современных журналируемых файловых систем для Linux

По моему тут тестировалась не файловая система, а сетевые возможности операционных систем, и я думаю, что никто спорить не будет, что у линукса tcp стек намного лучше, чем у виндовса, ты бы еще с nfs с линукса на линукс сравнил! ;)

anonymous ()

Re: Re: Re: Анализ современных журналируемых файловых систем для Linux

to anonymous: По поводу NTFS5X... вот стоит такая у меня на работе... стоит уже пол-года(!:-), при входе в каталог, я жду порядка 3-5секунд... пока файл начинает копироваться, я жду еще секунду.... скорость удаления каталогов ООчень медленная(а приходится часто работать с большими исходниками). Дефрагментация! скажете вы, дык что мне теперь дефраментатором винт мучать каждый день???
по поводу reiser: вот стоит у меня дома, полтора года уже(а может и поболе...) и почему-то не замечаю с ней проблем... вот странность-то.

по поводу внутреннего устройства этих файловых систем и сравнивать нечего, сходите на сайт namesys и почитайте как устроен reiser, а потом сходите в дефрагментатор NTFS и посмотрите на некий системный файл(MFT, кажись зовется), разползшийся по всему диску и попавший во все дыры.

и еще.. нельзя провести объективный тест NTFS и AnyLinuxFS, т.к. они работают под разными OS. Их можно было бы сравнить, если бы устройство NTFS было открыто со всеми ньюансами и с объяснениями для чего и почему существует там та или иная фича.

dimonb ()

Re: Анализ современных журналируемых файловых систем для Linux

По поводу сжатия- смотрите man chattr. На ext2 сжатие есть! И ещё много чего! Например: chattr +a file_name.

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Господа. Насколько я понял, и XFS и reiserFS и NTFS журнализируют только метаданные (иноды, описания каталогов), а вот сами данные не журнализируют. И метаданные и данные журнализирует только ext3. Что выбрать - XFS или другие FS. По отзывам, XFS самая продвинутая и доведенная до ума система. Вот только в журнализации данных загвоздка.

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

По поводу тестирования дисков Самбой:

Тест был произведене неверно и не были произведены хотя бы предварительные настройки. Например не был увеличен размер буфера передачи у Win2000/Win98. По умолчанию они не совсем оптимальные.

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

Я не хочу сказать, что кто-то круче, а кто-то нет. Я говорю о элентарном профессионализме.

and3008

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Когда же Вам надоест давать ссылки на англоязычные источники!?? Но это так, не по теме; просто наболело.

А если уж говорить о журналируемых ФС, то где NTFS? Тем кому интересно, могут прочитать о ней по адресу: http://www.ixbt.com/storage/ntfs.html

Прошу заметить: НА РУССКОМ ЯЗЫКЕ !!!

gik ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

Всё было честно: Самбу я тоже не настраивал :-).

Ко всем другим: эксперимент этот задействовал много компонентов. В том числе и сетевые, я же сделал допущение того что раз сеть 100М/бит значит и тестились в основном быстродействие файловых систем (винты одинаковые).

Кто-то считает, что у МД2000 стек TCP/IP сделан плохо ??? Тада чё вы тут доказываете что она (МД2000) лучше ? :-))).

"В человеке должно быть всё прекрасно: погоны, какарда, исподня ... " (с) ДМБ

А почему про ОС мы так судить не можем. Мне например дела нет никакого
(в этом тесте) кто и что там по умолчанию правильно настроил :-). Я просто взял и померил скорость без ковыряния хитрых опций у обоих систем. Считаю6 что поступил как большинство народу.

Ну и вот ещё что, конечно же Вам не сказал, что когда сеть была 10М/бит, то скорости туда/сюда были одинаковые :-) Ну тут я виноват конечно ... но выходит, что на 10М/бит стеки протоколов TCP на всех машинах одинаково работают, а вот на 100М/бит вдруг Линукс всех делает ??? Странно странно ... но я для себя решил какая же файловая ситсема всё-таки лучше :-) КОнечно же ext3. Пусть каждый использует то, что ему больше подходит, я просто рассказал о своих наблюдениях.

Warmonger ()

Re: Анализ современных журналируемых файловых систем для Linux

нет смысла журналировать _данные_ если нет соответствующего api .. далее. журнал нужен не для достоверности данных, а как средство избавления от fsck.

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Но ведь ext3 журнализирует и данные. Как там насчет api? И кто вообще за достоверность отвечает?

anonymous ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

А когда же Вам, сэр , не надоест лезть сюда со своими виндами всуе??? Статья, на которую была сделана ссылка - называется Journal File Systems in Linux. В ней, прошу заметить, речь о журналируемых файловых системой ПОД LINUX. А ссылки на тесты даны в разделе ресурсы и не являются предметом рассмотрения автора статьи. Ну причем тут NTFS????, уже есть исходники под линукс? И уж тем более лезть сюда учить какие давать ссылки, какое отношение к линуксу имеет данная Вами ссылка?? Собственно тоже наболело.

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

2AlexM

AlexM - имя Vampire тебе не о чем не говорит?

Lost_Tux ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

А шибка умный онанимус не знает, что на сервере как раз ЖФС и не нужна, потому как сервер на ИБП висит. А вот дома ЖФС нужна ещё как, потому как електричество мигнёт - и вперёд, восстанавливайся с бэкапов.

Про идиотскую по нынешним временам (80Gb винт - по цене грязи) возможность прозрачного сжатия файловых данных - см. патчик e2compr для ext2.

Ну и про UFS не надо, ибо она obsolete по причине наличия присутствия FFS.

В общем, тов. ламер, идите учиться. А то вы блэдно смотритесь.

Antichrist ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

А ну быстро в сад! На перевоспитание.

Журналирование файловых данных в идеологии юникс-подобных систем невозможно в принципе, так как отсутствуют способы определения целостности данных - файлы плоские, неструктурированные. Так что про ext3 - гонево полнейшее.

Antichrist ()

Re: Анализ современных журналируемых файловых систем для Linux

Прочитал статью. Но то ли ума не хватает, то ли с английским слабовато - чем отличаются кэш-буфер от page-buffer?

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Antichrist - если в юниксах это невозможно, то где это возможно? И как определяется целостность данных?

anonymous ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

Там, где файловая система ближе по структуре своей к базам данных. К примеру, в RMS (под OpenVMS) - там файл не обязательно плоский, пользователь может задать весьма произвольную структуру, и ОС будет этой информацией пользоваться при кэшировании и журналировании обращений к файлам. Естественно, с такими файлами работать надо совсем не через open/read/write/seek, это больше на работу с БД похоже.

Antichrist ()

Re: Анализ современных журналируемых файловых систем для Linux

А что значит - "плоский"? Не догоняю. Кстати, а как в БД поддерживается целостность? И еще - OpenVMS действительно такая крутая ОС, как ее описывают в рекламе? Что в ней такого особенного, чем она лучше юникса, НТ?

anonymous ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

buffer cache imeet otnoshenie k sohraneniyu v pamyati blockov
ot block device naprimer IDE diskov.
Page cache imeet otnoshenie k stranitsam virtualnoi pamyati poetomu i "page".
V ubnifitsirovanom cache blocki na diske mapyatsya v ye zhe stranitsy pamyati
i dostup (naprimer sbros "dirty" stranits na disk) osuschestvlyaetsya cherez stranitsy v pamyati kotorye sootvetstvuyut blockam na diske.

Uman

anonymous ()

Re: Re: Re: Анализ современных журналируемых файловых систем для Linux


2Antichrist (*) (2002-01-27 16:24:44.0):
> А шибка умный онанимус не знает, что на сервере как раз ЖФС и не нужна,
> потому как сервер на ИБП висит.
Извини, приятель, давно за тобой слежу - частенько ты пургу гонишь.
Ни в чем ты ни в зуб коленкой, но рожи умные корчить горазд.

> на сервере как раз ЖФС и не нужна
Т.е. ты и с серверами дел не имел.

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

А пока не поймешь, будут тебя юзера вспоминать не злым тихим словом...

Die-Hard ★★★★★ ()

Re: Анализ современных журналируемых файловых систем для Linux

Да, вдогонку - кончай мозги впаривать про "неплоские" и "многопоточные"
ФС - вас тут только двое таких, ты и Irsi, и ни каких серьезных аргументов
за неск. лет никто из вас не привел.

Die-Hard ★★★★★ ()

Re: Анализ современных журналируемых файловых систем HOREZ

Я кстати, работал на весма многопоточной ОС - и ничего, все ок было!.

ananymous ()

Re: Анализ современных журналируемых файловых систем для Linux

>В ней, прошу заметить, речь о журналируемых файловых системой ПОД
>LINUX.
Если идет речь про Линукс, то не надо постить новости о преимуществах между eXT2 перед ФАТ32 (в родные линуксу системы она не записывалась).
>Ну причем тут NTFS????, уже есть исходники под линукс?
Дело в том, что криворукие линуксойды до сих пор не могут написать поддержку чужой _продвинутой_ файловой системы, иной чем ФАТ32. До сих пор гоняют 2 года в альфе в ro.
Кстати, как могут быть исходники ФС. Описание, насколько я знаю, даёт сама МС.
>Собственно тоже наболело.
Полечи

anonymous ()

Re: Re: Re: Анализ современных журналируемых файловых систем для Linux

2Warmonger: а почему было сделано допущение что тестируются именно ФС ? Как было правильно в первом твоем сообщении замечено на 100-ке в лутчшем случае при ясной луне и хорошей погоде получишь не более 10 мегабайт в секунду, а сегодняшние идешники легко дают 20 мег в секунду. И где тут тест ФС ?

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Не удержусь и тоже метну слово для товарища anonymous (*) (2002-01-27 20:48:18.0)
Исходники файловой системы - да. Бред. Но спецификация, подробное описание того, что, куда и где - извини, у мелкомягких закрыты :((
Только общее представление, да видимо кусочки побольше производителям дефрагментаторов.
А писать ФС на reverse ingeneering'e - неблагодарное дело. Вспомни как все орали когда ICQ старый протокол закрыли - теперь клиенты даже искать по white pages не умеют :((
Сам подумай, кому нужны эти кучи систем - несколько лет жили под ext2 и в ус не дули. А поддержка ntfs - гора-аздо больше нужна среднему юзверю, нежели новая навороченая журналируемая ФС. Хотя конечно и последняя тоже нужна, мамы всякие важны...
Все вышесказанное - мое ИМХО.

Botsvein ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

>Дело в том, что криворукие линуксойды до сих пор не могут написать поддержку чужой _продвинутой_ файловой системы, иной чем ФАТ32. До сих пор гоняют 2 года в альфе в ro.
А нафига собственно говоря козе баян? Зачем мне нужен этот НТФС если у меня на диске масдаем и не пахнет?
>Кстати, как могут быть исходники ФС. Описание, насколько я знаю, даёт сама МС.
Да вертел я на одной конечности весь МС с её дырами...

CyberDem0n ()

Re: Анализ современных журналируемых файловых систем для Linux

2Botsvein: "что, куда и где - извини, у мелкомягких закрыты "
Так напишите свою приличную, но ведь какое дело не могут, максимум на что способны так это журнал к ext2 приделать, причем в скорости все тот же отстой.

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Статья как бы между делом рассказывает, что unified buffer cache в Linux только с 2.4.10. Неплохо для самой "продвинутой" OS столетия. :)

anonymous ()

Re: Re: Re: Re: Анализ современных журналируемых файловых систем для Linux

Ишь, ещё один шибко умный выполз. Да если сервак грохнется, то уже по фиг, сколько там гиг дисков - юзеры по любому убьют. Сервак не грохнуться должен, а сделать аккуратный шатдаун. Если же админ настолько мудак, что не может такое поведение обеспечить, и прикрывает свою рваную жопу всякими там журналируемыми ФС - то стрелять такого админа.

Antichrist ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

Плоский - значит, "файл прямого доступа". В котором ты любой байтик напрямую поменять можешь (реально - любой блок). Структурированный же файл состоит из "записей", которые могут быть взаимосвязанны.

Ну а OpenVMS - просто *другая* ОС. Не юникc, не НТ. Для некоторых задач оказывается многократно лучше, надёжнее и производительнее любых других альтернатив, для других же задач - почти неприемлима. Чтоб понять, что это такое, надо самому руками пощупать.

Antichrist ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

А ты найди, невменяемый онанимус, где в обсуждаемой статье упомянуты NTFS и/или FAT32. Потом уж пытайся из себя умного корчить, публику смешить.

Antichrist ()

Re: Анализ современных журналируемых файловых систем для Linux

Да, флейму то развели , а ехт2 старая ужэ однака........ Но лучшэ фат это точно. Никаких фактов, если кому нужны, но у каждой фс есть свои плохие и хорошие стороны. Для каждой задачи шото своё. Ужэ было такое , я поторяюсь.

manowar ★★ ()

Re: Анализ современных журналируемых файловых систем для Linux

>А ты найди, невменяемый онанимус, где в обсуждаемой статье упомянуты
> NTFS и/или FAT32. Потом уж пытайся из себя умного корчить, публику
>смешить.
Кончай тут себя гением выставлять. Страничку в браузере крутил не глядя и ещё п@@@ишь..
Если читаешь по-английски, то нужно было врубиться, что основная часть статьи - это бенчмарки (там ссылочки снизу были - http://bulmalug.net/body.phtml?nIdNoticia=626). И там сравнивают линуксовские ФС с ФАТ32. По-испански, правда, но гугл перевел нормально :-)
Так чё опустили мы тебя :-) Перехристись..

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Нравятся мне убедительные высказывания мистера Antichrist'a. Сразу видно - перец слов на ветер не бросает. Еще пару-тройку возражений и по понятиям пойдет. Складывается такое ощущение (ИМХО, конечно), что данный многоуважаемый крендель вообще лишен способности что-либо конструктивно аргументировать: если по Вашему, Мистер Antichrist, мнению, аудитория не просекает фишку, то просветите аудиторию, расскажите, что да как, а не пытайтесь вылезти из затруднительного положения с помощью исключительно субъективных высказываний. И потом, если уважаемый Мистер снизойдет до такого отношения к аудитории, то видимо никто больше не назовет его "гонцом пурги" и прочими красноречивыми погонялками... ;-) Личное: Перец, ты вообще слыхал когда-нибудь о таком понятии, как профессиональная этика? Или ты до сих пор остался подростком и считаешь себя самым наикрутейшим хакером в нашей матрице? ;-)

С глубоким уважением, proff.

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

>Ишь, ещё один шибко умный выполз. Да если сервак >грохнется, то уже по фиг, сколько там гиг дисков - юзеры по >любому убьют. Сервак не грохнуться должен, а сделать >аккуратный шатдаун.

Ага, а чё ты будешь делать, когда у тебя UPS внезапно сдохнет? (Между прочим такое в моей практике было)

другой anonymous

anonymous ()

Re: Re: Анализ современных журналируемых файловых систем для Linux

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

Между прочим, не самый маленький банк, уже который год успользует неЖФС под основной БД - и ни одного сбоя, почему? Потому как UPSы правильные, сами горели а напряжение всё же несколько минут держали.

rabbit ()

Re: Анализ современных журналируемых файловых систем для Linux

To Antichrist & rabbit:

Про УПС в серверной ну полный гон. Разные ситуации бывают. Например, друг у меня работает во Владике, так у них пару-тройку лет назад ,%издец с електричеством был. Могли отключать на 10-11 часов, причем без всякого графика. Так им некакие ИБП не помогали. Пришлось покупать дизеля. Другой пример - напряжение может скакать в течение ограниченного периода времени и разрядить батареи до нуля. Если конечно стоит ИБП с дублированием модулей и батарей типа Powerware 9170 или Nfinity, то тогда да, проблем будет намного меньше. Но не все могут отдать 15-20 килобаксов за ИБП пусть даже для сервера. Так-что ЖФС для сервера как раз таки и нужна.

alexros ()

Re: Re: Re: Re: Re: Анализ современных журналируемых файловых систем для Linux

>Сервак не грохнуться должен, а сделать аккуратный шатдаун это если мама грохнется? Да, батенька, не было у вас катострофических отказов оборедования, одно слово - Antichrist (видно с ... спутался)

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

2 Antichrist: Основываясь на Ваших высказываниях, Вы по момему даже НТ сервак на ФАТ32 ставите. :)

gelios ()

Re: Анализ современных журналируемых файловых систем для Linux

2 Antichrist:
Основываясь на Ваших высказываниях, Вы по момему даже НТ сервак на ФАТ32 ставите. :)

gelios ()

Re: Анализ современных журналируемых файловых систем для Linux

2 Antichrist:
Основываясь на Ваших высказываниях, Вы по момему даже НТ сервак на ФАТ32 ставите. :)

gelios ()

Re: Анализ современных журналируемых файловых систем для Linux

Грусно. Опять все вселось к обсуждению Linux vs Windows.

Господа, юзающие Windows! Ну чё вы сюда прётесь? Господа, юзающие Linux! Ну чё вы гоните пустое на Windows?

Обе системы хороши и самый умный тот, кто их грамотно применяет в своей работе.

Тестировщику дисков через Самбу: Провел тест ты не профессионально и дал повод для нападок. В частности не оптимизовал стек TCP/IP. Если бы ты это сделал, то вопросов было бы меньше. Да и сам тест - это не тест файловой системы, а еще и сетевая производительность. Т.е. тест очень даже ситнетический и не отражает реальное положение вещей. Вызывает больше вопросов, чем ответов.

И заканчивайте эту глупую лайню. Кому надо ЖФС - тот поставит. Кому не надо - не поставит. Кто не знает что это такое - пусть ждет пока все грохнется. Горький опыт - самый правильный и надолго запоминающийся.

UPS - штука хорошая, но хороший UPS стоит весьма и весьма недешево. Например дешевые модели UPS от APC сами дохнут. Плата управления у них летит. Лично два таких возил в сервис-центр.

NTFS - штука тоже хорошая, но имеет небольшой баг, когда копируется очень большой файл средствами Explorer. Проблема с потоками. Микрософт рекомендует такие файлы копировать прогами типа copy.

Создание новой файловой системы с нуля - вещь довольно сложная. Так что не надо ждать, что появится супер-пупер ФС за несколько месяцев. NTFS тоже сейчас только улучшают, а не разрабатывают с нуля. Так что не надо на эту тему тоже флеймить.

В общем грусно. Хотелось услышать конкретные отзывы, а получилось как всегда.

and3008

anonymous ()

Re: Анализ современных журналируемых файловых систем для Linux

Такой "непрофессиональный тест" случился сам собой недавно и у нас в конторе. Надо было перелить 25 гигов файлопомойки (половина - мр3, половина - доки, архивы и дистрибуты) с одной машины на другую. Машины идентичны (Windows2000 Advanced Server, NTFS, max netwowk&disk troughtput), только на одной (куда лилось) два P933 и 1 гиг памяти, на другой (откуда) - один проц и 256мег - сист. платы, видюхи и диски (IBM 40G, ide, 7200rpm) одинаковые. Сеть - 100мбит, NICs&hub - Intel. Запускаем копирование, смотрим график трансфера. Что за дела - секунд двадцать идет 6.5 mb/sec, потом пила и падение до 1.5, секунд десять держится этот скромный уровень, потом снова поднимается до 6-7. И такие циклы до самого конца небыстрого процесса. К концу минимальный уровень стал снижаться аж до менее чем 1 мб/сек - такового даже на Win95 наблюдать не приходилось... Время нерабочее - посторонней активности в сети никакой.

Далее происходит следующее: диски меняются в компах местами и на тот, где 2 проца, ставится из коробки (точнее - слитый из фтп:)) SuSE Linux 7.3 c ядром 2.4.10, ext3 и быстренько (оптимизация и патчи потом будут) самбой (2.2.1a) отдатся шара в сеть и процесс копирования тех же 25 гигов запускается по-новой на том же самом железе, но на этот раз машина Win2000AS льёет на Linux/Samba. О чудо (возрадуйтесь еще раз фанатики-линуксоиды!) - график показывает стабильно около 8 mb/sec! Колебания есть, но не на порядок, а скромненькие такие +/- 400 кил - и от начала и до конца...

Присутствовавшие при этом виндовые люди сказали, что так оно вроде и нормально, беспокоится о кривости установки Win2000 нечего - причина в NTFS, коей надо время на перестройку-выделение чего-то там у себя в файловой системе когда на нее так много и непрерывно валят. Соглашаться или нет - не знаю. Но на Експлорер (на 2х камнях и гиге оперативки!!!) или реализация IP стека (кажется ведь BSD-based и самый-рассамый ;)) все свалить вроде не получается. Да и вспоминается, что еще в году так в 95ом кто-то тыкал меня пальцем в подобные несуразности, когда я его агитировал за переход на NT 3.51+NTFS вместо Novell, было дело :))).

Ну а несколько позже (когда запустили Оракл с JSP) окончательно стало ясно, что одним Windows2000 Advanced SERVER'ом в мире стало меньше, а СЕРВЕРОМ под Линуксом и ДЕСКТОПОМ под ним же - больше.

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

Поэтому, где можно мы Линукс и поставим - его администрить сил хватает, оно ведь один раз делается - а дальше только конфиги копируй да рихтуй помаленьку - это не registry keys учить и заново выставлять! И заранее знать при этом, что скоро все равно переучиваться, экзамены пересдавать, сертификаты обновлять - в M$ ведь опять все поменяют или уже поменяли, на радость тем, кто кормится от процесса, а не от результата.

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