>Вообще странно. ext3 всегда сливала всем ФС на rm -rf, сколько её помню.

Лог я свой дал. Это не случай, если я мог где-то опечатку допустить. Хотя на глаз проверял всё, кроме ext2 и второй половины тестов jfs - они шли, когда я дочку выгуливал :) Тесты тоже дал, можете проверить. Естественно, заполнение музыкой придётся на что-то своё переписать...

>тест, простите, чего?

Там написано. По-русски. Если русский не воспринимаете, попробуйте воспользоваться translate.google.com

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

ОМГ! Чё ты делал с компом? Рокетджампил?

>Для XFS UPS не обязателен. У меня неоднократно вырубало питание

Точнее так - блок питания на Active FPC может вообще не ребутнуться, когда обычное компьютерное и сетевое оборудование перезагружается либо виснет при бросках.

>Попытался открыть полученный .xlsx в OOo - не вышло

*качая головой*: ай-я-я-й, мы пытаемя бороться с этой заразой, а ты... Эх... :)

>Ну уж в следующей версии постараюсь сделать получше :D

А ведь следующего раза может и не быть - помни про Патрега! ;)

>А ведь следующего раза может и не быть - помни про Патрега! ;)

патрег умер?

к ночи не поминайте

>>Где скорость диска? Где размер его кеша? Что, уже от этого ничего не зависит? Где....

а оно менялось?

Патрег следит за вами. Через рфиды. ))

thx

Посмотрел на разпаковку архива и не поверил)

(~)->mount |grep xfs
/dev/sda3 on / type xfs (rw)
/dev/sda4 on /home type xfs (rw)
/dev/sdb1 on /mnt/fs-test type xfs (rw)
(~)->cd /mnt/fs-test
(/mnt/fs-test)->ls -l
итого 45644
-rw-r--r-- 1 root root 46737783 2008-06-12 00:41 linux-2.6.24.tar.bz2
(/mnt/fs-test)->time tar xfj linux-2.6.24.tar.bz2
tar xfj linux-2.6.24.tar.bz2  13,71s user 3,12s system 103% cpu 16,185 total
(/mnt/fs-test)->

Остальное не тестил) 

их h264 побил

С xfs у парня явно что-то не так.
Я аж испугался и провел пару тестов.
Распаковка 34 сек.
Удаление 7 сек.
На /usr с райзером распаковка 24 сек, но там софтрейд0.

>>Удаление файла на 30 гигов.

>Задача нечастая. Очень нечастая :) Кроме того, у меня свободный раздел сейчас только на 2Гб.

Не поверишь, у меня есть некая система скриптов, которая сначала создает, а потом удаляет файлов на 300 гигов в сутки.

>>Да, но фрагментация...

>А, да. Это смутило.

Дык монтировать reiserfs надо было с notail, иначе она все в хвосты пытается упаковать -- поэтому и фрагментация, и потеря производительности, и куча свободного места.

> у меня есть некая система скриптов, которая сначала создает, а потом удаляет файлов на 300 гигов в сутки.

Ты извращенец. Наверняка это можно было сделать по-нормальному.

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

здесь обсуждается _разница_скорости_ работы фс
а не то как хфс работает у тебя.

2all
и пожалуйста не нужно приводить примеры что usr на reiser сливает по полной xfs на home
разделы разные, дальше думайте сами

> Кстати, что скажете насчет jfs — чем оно хорошо?

Оно нормальное. Звезд с неба не хватает, но как на любой десктопной, так и серверной загрузке ведет себя очень сбалансировано и производительность не просаживается. Фич меньше, чем у xfs; косяков тоже (особенно если питание рубят). По надежности сравнимо с ext3, по скорости обгоняет, на очень больших разделах быстрее и приятнее, чем ext3; там ее и стоит использовать. За ней не водится вороха "страшных" историй, как это наблюдается с reiserfs и (отчасти) с xfs. Системные разделы, а так же небольшие (десятки гигабайт и меньше) от jfs выйграют не сильно, лучше оставить ext3, разве что если хочется получить некоторую прибавку к скорости на некоторых операциях, можно связаться (в общем, это относится почти ко всем фс).

Просто выглядит уж больно неправдоподобно)

в свое время был у меня свободный для тестов сервак
я проводил подобные тесты, только ехт4 еще небыло
так вот все винтажные фс типа хфс жфс даже рейсер сливали точно также ехт3
для себя вывод сделал.

Ну и? XFS медленная на мелких файлах и быстрая на больших, что не удивительно.

Кстати, а код XFS не пользует случаем BKL?

>> Для XFS UPS не обязателен.

ага у меня тоже питание вырубило - после старта - в половине файлов которые были на тот момент открыты - одни нули! Так было несколько раз на разных комп ( ХFS and refiser ) с тех пор только на ext3....

>У меня /home на reiserFS и че теперь делать? :'(

А до этого у тебя вопросов не возникало? Так почему ж сейчас засуетился?

>Да, но фрагментация...

И че?

Недавно у меня ext3 показывал non contiguous ~=10% и скорость чтения упала до
1 Mb/Sec.

Так что интересно бы посмотреть как эти fs себя ведут при сильной фрагментации, то что ext3 себя никак ведет - я уже видел.

Необъективно.

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

По теме: нужно избавляться от привычки, навязываемой MS - искать универсальные способы решения задач. А то можно дойти до того же, до чего добралось их подразделение, которое Офис разрабатывает - печатать тексты в медиапроигрвателе с элементами квеста и аркады...

Разные файловые системы предназначены для разных задач. Единственнное, что имеет смысл обсуждать - какая FS какую задачу решает лучше. Ну и надёжность. Впрочем, и тут не всё однозначно. Главное - предсказуемость результатов.

Пример того, как не надо делать тесты. Тоже результат, впрочем.

> Поясняю. Я данные по мере появления их в финальном логе, вбивал в Pocket Excel на КПК.

Еретик!! На костер его, сжечь, сжечь, СЖЕЧЬ!!!

А слабо с помощью filebench тестировать?

http://sourceforge.net/projects/filebench/

Любитель разносортных велосипедов без рефакторинга?

Ну что сказать? Дичайшая фрагментация всех без исключения линуксовых файловых систем — до UFS2 ещё не доросли.

P.S.
У меня за время эксплуатации UFS2 (2 года) фрагментированность ФС не превышает 5% даже на тех разделах, где проводится перекомпиляция и обновление ПО (раздел /usr, прежде всего). А компилирую я много...

dd if=/dev/urandom of=/dev/null круче

> Дичайшая фрагментация всех без исключения линуксовых файловых систем — до UFS2 ещё не доросли.

Рекомендуете??

>Рекомендуете??

Ага. Вместе с FreeBSD.
Да и на флэшках UFS2 отлично себя ведёт, шлака нет.

arceny@Metal-Alpha /drive1 $ time tar xf /drive3/Linux/gentoo/distfiles/linux-2.6.24.tar.bz2
real	0m42.981s
user	0m26.958s
sys	0m3.856s
arceny@Metal-Alpha /drive1 $ time rm -rf linux-2.6.24/
real	0m11.235s
user	0m0.036s
sys	0m1.708s

XFS ^^^^

arceny@Metal-Alpha ~ $ time tar xf /drive3/Linux/gentoo/distfiles/linux-2.6.24.tar.bz2
real	0m40.221s
user	0m26.866s
sys	0m5.584s
arceny@Metal-Alpha ~ $ time rm -rf linux-2.6.24/
real	0m1.913s
user	0m0.020s
sys	0m1.800s

ReiserFS ^^^^

Кстати, повторюсь. XFS ни разу не падал. Как и reiserFS. Ext3 один раз унёс системный раздел, больше его не использую. Ну и , субъективно, тормоз.

arceny@Metal-Alpha /drive1 $ dd if=/dev/zero of=test bs=1024 count=1048576
1048576+0 записей считано
1048576+0 записей написано
 скопировано 1073741824 байта (1,1 GB), 12,9155 c, 83,1 MB/c

arceny@Metal-Alpha ~ $ dd if=/dev/zero of=test bs=1024 count=1048576
1048576+0 записей считано
1048576+0 записей написано
 скопировано 1073741824 байта (1,1 GB), 22,7435 c, 47,2 MB/c

Парадоксальные результаты. Особенно по xfs. По теме есть интересные доклады с Linux Symposium.
http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf
Правда доклад от сотруднигов SGI :)
По фрагментации - что это такое, какие виды фрагментации бывают хорошо описано тут
http://ols.108.redhat.com/2007/Reprints/sato-Reprint.pdf

>> народ, а почему xfs так себя плохо показала ?

> Я сам удивился.

Дык ты на чем тестировал?
На исходниках ядра, а это большая куча _мелких_ файлов.

Странно, что xfs и reiserfs выглядят так дерьмово

>P.S. У меня за время эксплуатации UFS2 (2 года) фрагментированность ФС не превышает 5% даже на тех разделах, где проводится перекомпиляция и обновление ПО (раздел /usr, прежде всего). А компилирую я много...

А у меня за 6 лет эксплуатации ext3 фрагментированность не превышает 5.6%. У меня пиписька больше. ага?

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

Ещё раз повторюсь для Ъ: в описанном тесте не преследуются глобальные цели и не делаются выводы. Тесты посвящены двум конкретным задачам. Читайте перед ответом, а то комментарий получается не по теме.

озу 2 Гб, тестовый раздел 300 Мб. имхо протестирована производительность подсистемы озу.

>озу 2 Гб, тестовый раздел 300 Мб. имхо протестирована производительность подсистемы озу.

Кстати, не лишённое логики замечание. Вот если бы раздел был хотя бы 2 гига...

>На мой взгляд ext* медленно работает с большими директориями.

для тех у кого тормозит:

http://www.opennet.ru/tips/info/1345.shtml

Влияние лунного света на рост телеграфных столбов.

> > народ, а почему xfs так себя плохо показала ?

IMHO, потому, что автор заранее знал, какой ему нужен результат, и специально
сконструировал тест.

1. Маленькая ФС (2 Gb).
2. Практически полностью заполненная. При этом производительность резко
падает (у любых ФС, а тем более у extent-based).
3. Много операций с мета-данными (копирование/удаление мелких файлов).

Можно сконструировать тест, в котором плохо себя покажет ext3:

1. Запись/чтение одновременно из нескольких процессов/потоков.
2. Удаление больших файлов.
3. Операции с большими директориями (a la MailDir).

> Я сам удивился.

А чего удивляться-то?

> Не люблю эту ФС,

Хотелось Вам увидеть, что XFS плохая -- Вы это и увидели.

>На исходниках ядра, а это большая куча _мелких_ файлов.

В принципе, для Linux достаточно характерно :)

>озу 2 Гб, тестовый раздел 300 Мб. имхо протестирована производительность подсистемы озу.

Перед каждым измерением при наличии в кеше данных, способных повлиять на результат, я делал «сброс кеша» путём копирования на локальный раздел (не тестируемый) 2Гб мелочёвки с удалённого диска. В скрипте и логах это отражено.

>Вот если бы раздел был хотя бы 2 гига...

Раздел, как раз, на 2Гб. И забивался под завязку. Читайте внимательно описание задачи, там всё указано.