XFS vs JFS vs ext2/3 (выбор FS)

[ShinobiTeNo]

ВОТ, ЧИТАТЬ!!

http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs7_ru.html

Ктонибудь может сказать,есть ли в XFS или JFS возможность засечения и коррекции плохих блоков???

По ходу ext3 wins! Только надо руки прямые иметь.

[eR]

про JFS на http://www.ibm.com/developerworks/ статьи есть.

вот ещё статься про XFS http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs9_ru.html

Ктонибудь может сказать,есть ли в XFS или JFS возможность засечения и коррекции плохих блоков???

а что это?

ВОТ, ЧИТАТЬ!!

http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs7_ru.html

Ктонибудь может сказать,есть ли в XFS или JFS возможность засечения и коррекции плохих блоков???

По ходу ext3 wins! Только надо руки прямые иметь.

LOL nоко щас ссылку нашёл)))))

на форуме быстрый ответ тупит.

По ходу ext3 wins! Только надо руки прямые иметь.

при прямых руках и с xfs/jfs можно жить.

[ShinobiTeNo]

ИТОГО:
(субъективное)

Интересно то, что ext3 выполняет journaling совсем иначе, чем ReiserFS и другие journaling filesystems. В ReiserFS, XFS и JFS filesystem журналируются метаданные привода и не предусмотрено какое либо журналирование самих данных. При metadata-only journaling метаданные хранятся так надежно, что, скорее всего вам не придется пользоваться fsck. Однако, неожиданные перезагрузки и сбои в электропитании могут приводить к утере данных, которые в момент сбоя записывались на диск. Ext3 использует несколько творческих решений для избежания таких проблем.

Сначала поясним ситуацию с metadata-only journaling. Например, вы редактировали файл /tmp/myfile.txt в момент, когда машина неожиданно блокировалась. В случае с metadata-only journaling filesystem (например, ReiserFS, XFS или JFS) ваши filesystem метаданные утрачены не будут и запуска fsck не потребуется.

ОДНАКО, в случае такого сбоя имеется высокая вероятность, что в файле /tmp/myfile.txt останется один МУСОР, а то и просто он станет нечитабельным.

Причина в следующем. "Обычные" journaled filesystems, подобные ReiserFS, XFS и JFS опекают метаданные, но для повышения производительности заботу о данных не проявляют. В нашем примере происходила модификация некоторых filesystem блоков и соответствующих им метаданных, но синхронизация была неожиданно прервана. "Непротиворечивость" файловых блоков будет восстановлена, чего нельзя сказать об их "наполнении".

+ Относительно положительные моменты
. Нейтральные моменты
- Относительно отрицательные моменты


XFS:

Данные хранятся в больших буферах:
+ Высокая производительность
+ Уменьшенная фрагментация
+ Высокая надежность кода
+ Присутствует дефрагментатор
+ Присутствует лог измений файлов...
- ..., но не данных.Если электричество вырубленно до того как буфер сброшен на диск, лог покажет,что файл ожидал записи,но не был записан и весь файл будет заполнен НУЛЯМИ при следующей загрузке. ДАННЫХ ТО НЕТ. Предполагается это должны желать сами программы...
. Невозможность восстановить удалённые файлы.(нет функции и утилит undelete), удаление с обнулением(возможно причина низкой скорости удаления)
- Для обработки и проверки системы требуются большие объемы памяти.
- Для обработки и проверки системы требуются большие вычислительные мощности.
- Отсутствует контроль над плохими секторами(физическими повреждениями диска), предполагается,что это должна делать утилита.. без нее можно нарваться на сбой, когда будет уже поздно.
- Низкая отказоустойчивость если ошибка обнаружится в ОДНОЙ из структур XPS.
- Нельзя уменьшать размер диска
- Нельзя загружаться как boot. Проблемы если /, так как может стать затертым.
- Низкая скорость стирания данных

Идеальное место применения:
= Только там, где есть UPS.
* обработка критической по времени информации.
* сервера, имеющие дополнительно прог обеспечение,устраняющее приведеные недостатки.



JFS:
Данные храняться в динамических структурах
+ Высокая производительность, но только пока объектов в "ПОЛЕ ДЕЙСТВИЯ" мало.
+ Малая требовательность к ресурсам вообще.

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

Идеальное место применения:
???



EXT3:
Классическая надежная,но несколько медлительная организация системной структуры.
Режимы:

data=writeback
Хранит только данные об операциях. Очень быстрые операции.
- Проблема с скоросным режимом на жеских дисках некоторых ноутбуках. Некоторые современные диски имеют еще более "вредную" привычку без команды сбрасывать свой кэш(а не записывать), когда система перезагружается или "засыпает"(S1/3). Если есть такой диск, а файловая система поддерживает журнализацию writeback, происходит периодическое разрушение данных и нельзя ничего предпринять для предотвращения этого.

data=ordered mode
То же,что и writeback, однако запросы стандартны для ATA, пишутся и действия, и файлданные(ПУСТЫШКА), ЭТО СОЗДАЕТ ПРОБЛЕМУ:
- В случае краха велик риск перезаписи файла с новым именем/изменившегося мусором,так как данные не были зарезервированы, а информация о действиях дошла.

data=journal mode
Каждая операция совершается сначала в журнале, потом выполняется на диске. Пишутся все данные. Изза специфического устройства ATA, потери в скорости могут отсутствовать.

+ Производительность прямо зависит от настроенности.
+ Совместимость ext2-3-4.
+ Блок с таблицей плохих секторов и возможностями их засечения.
+ Три режима журнала и обратная совместимость с ext2.
. Слабый дефрагментатор,но и слабая вероятность фрагментирования(+_+)

- Трудноподдающийся дрессировке fsck... который тем не менее делает, о чем просят.
- Мало дополнительных опций против конкурентов, однако ext4 их предоставит.

Применение:
Или ext2, или ext3 journal mode. Повсеместно, для любых систем.

[eR]

переминовываю тему по просьбе ShinobiTeNo и по причине присутствия весьма аргументированого флейма.

ShinobiTeNo, добавьте в XFS ещё невозможность восстановить удалённые файлы.(нет функции и утилит undelete)

короче, перерыв пол инета, перечитав статьи, форумы и заключения ShinobiTeNo , я решил, что моему ноутбуку привлекательней будет XFS, потому что его недостатки для меня не критичны, а достоинства обходят другие FS.

если чё ещё нарою, выложу.

[eduard_pustobaev]

Ну раз тема переименовалась, да и во флейме... То хочу спросить почему все пренебрегают reiserfs(не reiser 4, а обычной reiserfs)?
Просто я как-то всегда использую либо ext3, либо reiserfs. И в принципе субъективно reiserfs кажется пошустрее.
Проблем таких, которые бы не решались посредством fsck/reiserfsck никогда не было.

[diesel]

eR.Ud опять таки если речь о ноуте:

- Для обработки и проверки системы требуются большие объемы памяти.
- Для обработки и проверки системы требуются большие вычислительные мощности.

гораздо важнее плюсов..... ибо энергопотребление, да.

[eR]

diesel, у мя бук не слабенький и в основном работает от эл. сети, поэтому не критично
eduard_pustobaev, хз, в сторону reiser3fs не копал.

[ShinobiTeNo]

Сделал коррекцию!
Я копал почти во все стороны.

Из того,что я накопал насчет Reiser могу вынести следующие факты:
(Как дополнение к материалам выставленным на Wikipedia)

-Задумывается система для серверной планки - непритязательность к ресурсам, быстрая обработка больших количеств файлов, устойчивость итд.
-Названа в честь главы комманды, Hans Reiser - ReiserFS.
-Для комманды это основной труд, то есть он проплачивается Novell/suse. Мотивировка в основном известность и деньги.
-Система реализует ряд относительно передовых технологий приминительно к таблице файлов - бинарные балансированные деревья итд, чья реализация судя по всему тяжеловата,но под силу.
-Медленно, но верно системка набирает обороты и третья версия получает признание, будучи еще не завершенной. Не все идеи выдвинуты и не все недостатки исправлены, тем не менее Hans Reiser считает это достаточным для v3 и начинает проект с чистого листа версию 4. Доделка багов поручается одному парнишке.
- Жена Reiserа убита, ведется следствие.
- Через некоторое время он сам становиться главным подозреваемым. Novell сразу снимает финансирование и оба проекта(3,4) замораживаются.


На теперешний момент мы имеем глючноватую, прожорливую и тормознутую призрак того, что должно было быть ReiserFS. Текущая версия 3 проигрывает по всем показателям, легко фрагментируема, нестабильна, несовместима с ext2 абсолютно, бедна свойствами. Ее официально рекоммендуют снять в пользу ext3/4 Sidux(Debian)...

Короче прочитайте мое мнение о перспективах тут ранее




eR.Ud не советовал бы я тебе ставить ни JFS, ни XFS.
Только по двум основным(и третьей производной) причинам:
1. Отсутствует контроль над плохими секторами. Начнет лететь винт, НЕ СПАСЕТ НИЧЕГО. Утилитки по бекапу не смогут это определить, сами J/X-FS об этом будут молчать. Все будет бэкапиться уже с ошибочными данными внутри. Если только косвенно начнут глючить программы или документы получат мишуру внутрь. Вообще эта "фича" меня убила наповал, даже старый FAT12 имел таблицу bad blockов.
2. Журналинг реализован на скорость. Тоесть он НЕ ПОЛНОЦЕНЕН! Для него затереть открытый файл нулями или мусором - плевое дело.

И наконец ФИЛЬНАЛЬНЫЙ рычажок который "легким движением руки" поворачивается одним из двух предыдущих факторов:
XFS: Абсолютная неготовность системы иметь ошибку внутри своих структур.
JFS: Нестабильность кода. Что в принципе может оказать тот же самый эффект, что и у XFS.

Результат один - чистый диск. Конечно вероятность, то небольшая, но с малого и начинается.
Вообще мне обе системы показались удивительно СТРАННЫМИ. С одной стороны такие плюсы,с другой такие пробелы. Хотя для ПОРТОВ(как вырезов из целого) это неудивительно. На их фоне ext3(правильно настроенный) смотриться просто академически.

Я ставлю ext3 journal mode, с перспективой апдейта на ext4.

[eR]

ShinobiTeNo, типо от чего ушли к тому и пришли? нет, я на ext3 не вернусь.

Я ставлю ext3 journal mode, с перспективой апдейта на ext4.

Я ставлю XFS, с перспективой апдейта на ext4.

думаю даные не забракуются

[eduard_pustobaev]

- Жена Reiserа убита, ведется следствие.
- Через некоторое время он сам становиться главным подозреваемым. Novell сразу снимает финансирование и оба проекта(3,4) замораживаются.

1) Novell забила на reiserfs до пропажи жены Рейзера.
2) Про Reiser4 я речи не вёл.

На теперешний момент мы имеем глючноватую, прожорливую и тормознутую призрак того, что должно было быть ReiserFS.

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

Текущая версия 3 проигрывает по всем показателям, легко фрагментируема, нестабильна,

Ну нет такого. Нет. Точнее может и есть но отнюдь не безапелляционный факт. Это очень спорный вопрос.
Reiserfs достаточно популярная и качественная ФС.

несовместима с ext2 абсолютно,

А разве должна? А ext3 несовместима с vfat, так что с того?

бедна свойствами.

Тут возможно, для ваших запросов. Меня например устраивает.

Ее официально рекоммендуют снять в пользу ext3/4 Sidux(Debian)...

И что? Почти все дистры по-умолчанию предлагают ext3, ибо лучше всего обкатано, испытано и проверено.

Короче прочитайте мое мнение о перспективах тут ранее

Так вот прочитал. И не понравилось. Так как звучит убедительно, а на деле обычное IMHO.
К тому же местами претензии маловнятные.

[eR]

eduard_pustobaev, дык он же и пишет, что мнение субьективное.

[rm_]

XFS очень плохо справляется с операциями по затиранию и нетолерантна к аппаратным сбоям. С нее нельзя /, разве что если boot в отдельной папке, но тогда, если она сломается, пратически невозможно загрузиться.

Корневой раздел на XFS уже давно можно, без всяких проблем. По крайней мере, если использовать LILO.
У GRUB были какие-то проблемы с этим, да. Не знаю, возможно и они уже исправлены.

По поводу Ext3. Вот таких результатов тестов:
http://linuxgazette.net/102/piszcz.html
лично мне вполне хватает, чтобы навсегда вычеркнуть её из списка современных файловых систем вообще.

JFS - хорошая ФС, её единственный недостаток для меня - это отсутствие работающего дефрагментатора подо что-либо, кроме IBM'овских старинных ОС (родных для JFS).

[ShinobiTeNo]

XFS очень плохо справляется с операциями по затиранию и нетолерантна к аппаратным сбоям. С нее нельзя /, разве что если boot в отдельной папке, но тогда, если она сломается, пратически невозможно загрузиться.

Корневой раздел на XFS уже давно можно, без всяких проблем. По крайней мере, если использовать LILO.
У GRUB были какие-то проблемы с этим, да. Не знаю, возможно и они уже исправлены.

По поводу Ext3. Вот таких результатов тестов:
http://linuxgazette.net/102/piszcz.html
лично мне вполне хватает, чтобы навсегда вычеркнуть её из списка современных файловых систем вообще.

JFS - хорошая ФС, её единственный недостаток для меня - это отсутствие работающего дефрагментатора подо что-либо, кроме IBM'овских старинных ОС (родных для JFS).

А зря....

Что мы имеем в железе, которое тестируется?

Одно и то же железо, на которых пашет разный код, с одними и теми же задачами.

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

Если Вы внимательно присмотритесь к этому рисунку с предыдущей сцылки, то до вас дойдет, почему же это так.
(Возможно также дойдет, почему это "вдвое медленней", на самом деле "в сто раз безопасней")





















Решение: ext3 был запущен в полноценном режиме "journal mode". Запустите его в "writeback" и картина изменится. Ext3 ЕДИНСТВЕННАЯ система,которая действительно уберегает от сбоев и их последствий. Ему разве что B+ Tree не хватает для большей эффективности...

[eduard_pustobaev]

eduard_pustobaev, дык он же и пишет, что мнение субьективное.

Да понятно. Но такие уверенные и однозначные выводы... Причём так вот сходу.
И главное все согласны...

Ext3 ЕДИНСТВЕННАЯ система,которая действительно уберегает от сбоев и их последствий.

Ну вот, опять...

[ShinobiTeNo]

eduard_pustobaev, дык он же и пишет, что мнение субьективное.

Да понятно. Но такие уверенные и однозначные выводы... Причём так вот сходу.
И главное все согласны...

Ext3 ЕДИНСТВЕННАЯ система,которая действительно уберегает от сбоев и их последствий.

Ну вот, опять...

....

Пошел настраивать kernel.

[eR]

http://www.mycomp.com.ua/text/4589
http://www.mycomp.com.ua/text/4543

[nonstop]

ИМХО
почему я выбрал JFS
журналируемая
проверка диска проходит очень быстро
на все появившиеся вопросы ребята из IBM ответили очень оперативно (такая проблема была)
на рабочих серверах AIX ну и ФС - JFS

не собираюсь никого уговаривать или спорить
каждому свое

опять же выбор не окончательный
подожду FreeBSD 7, а с ней ZFS (вот на ней, полагаю, остановлюсь )

[Torvinson]

Откуда информация, что работы над JFS под линюксом заморожены? На сайте http://jfs.sourceforge.net/ ничего не написано.

[rm_]

не советовал бы я тебе ставить ни JFS, ни XFS.
Только по двум основным(и третьей производной) причинам:
1. Отсутствует контроль над плохими секторами. Начнет лететь винт, НЕ СПАСЕТ НИЧЕГО. Утилитки по бекапу не смогут это определить, сами J/X-FS об этом будут молчать. Все будет бэкапиться уже с ошибочными данными внутри. Если только косвенно начнут глючить программы или документы получат мишуру внутрь. Вообще эта "фича" меня убила наповал, даже старый FAT12 имел таблицу bad blockов.

Если винчестер начинает лететь в плохие сектора, он эти сектора просто-напросто перестаёт считывать вообще.
Возвращает Read Error.
По этому поводу большой крик поднимает уже само ядро, даже не на уровне ФС, а на уровне блок-девайсов.
Кроме того, если ФС обнаруживает ошибку чтения, она по умолчанию перемонтирует себя в Read-only (это поведение контролируется опциями mount'а). Как раз для того, чтобы не запортить данные, продолжая работу на запись на неисправном девайсе (а винчестер с плохими секторами таковым и является).
Резюмируя - отсутствие управления бэд-блоками является лишь минимальным неудобством, приводящим к невозможности использовать частично "бэдовые" винчестеры в повседневной работе (а кто-то горел желанием?).
К каким-то катастрофам, страшным потерям данных и т.п., отсутствие этой фичи привести не может.

[AndreyKorytko]

Я копал почти во все стороны.
Я ставлю ext3 journal mode, с перспективой апдейта на ext4.

Весьма и весьма благодарен за обнародование полученных в результате старательных поисков выводов.
Лучшего анализа достоинств и недостатков доступных под Linux файловых систем найти не удалось.

[Torvinson]

Вот здесь интересный тест от ИБМ: http://www.ibm.com/developerworks/linux/li...journaling.html .

[crop]

Понимаю, что немного не по теме, но тем не менее:
кто что может сказать о разработке Sun - ФС ZFS? Интересует ее сравнение с уже рассмотренными ФС.

[eR]

crop
я ничё, ибо на десктопе его не постаить, а значит не нужно.

[serg86]

Всегда использовал reiserfs, ни когда не подводила, и по скорости намного быстрее ext3, и винт меньше грузит
IMHO

[serg86]

Алексей Федорчук выбирает Reiserfs , http://citkit.ru/articles/381/

[izen.fire]

опять же выбор не окончательный
подожду FreeBSD 7, а с ней ZFS (вот на ней, полагаю, остановлюсь )

Кстати, небольшое тестирование Ext3FS vs. ZFS:

Solaris ZFS and Red Hat Enterprise Linux Ext3 File System Performance White Paper

Explores the performance characteristics and differences of Solaris ZFS and the ext3 file system through a series of benchmarks based on use cases derived from common scenarios, as well as the IOzone File System Benchmark (IOzone benchmark) which tests specific I/O patterns.

[eR]

ну блин а разница? на десктопе ZFS не заюзать.

[Portnov]

С xfs несколько раз у меня случались крэш-тесты, довольно жесткие, на трех разделах - два по 40Г, один в 20Г. Ребут, проверка 20сек/раздел - все данные на месте.

[landgraf]

юзаю Ext3 постоянно (иногда ставил reiserfs) иногде случались отключения света (по разным причинам) вроде ничего не потерялось, да и жаловаться на длительную проверку не приходилось.

[Torvinson]

Тут интересный случай с ext3 получился. Отформатировал новый винт под эту ФС. Кинул туда около 300 гигов данных, перекидывая разделы. Потом удалил. Смотрю, а 40 гигов куда-то пропало. Т.е. данные удаились, в корзине ничего нет, проверка диска нормально проходит, ни потеренных секторов ни бэдов не обнаружено, ничего не находит, а 40 гигов пропали. Отформатировал в зарекомендовавшую себя jfs. Почему такое могло произойти?

Но что-то хранить данные на ext3 не хочется.