> time ( cat test.1 >/dev/null & dd if=/dev/zero of=test.2 bs=1M count=2048 )

И давно ваши сервера работают в таком режиме? Как программа называется?

> И какое мне поможет data=ordered?

А какая на твой взгляд фс может помочь в этом случае? По-моему только
скорая медицинская помощь тебе поможет... охладить воспалённое воображение.

> А какая на твой взгляд фс может помочь в этом случае?

Никакая, о том и речь -- журналирование данных БЕСПОЛЕЗНО. Потому его и нет ни в одной нормальной ФС, и только пЫонеры пытаются поднять себя за волосы...

>Из Linux'-овых ФС -- только к ext3. ReiserFS делает tail merging,
>XFS хранит мелкие файлы непосредственно в inode, etc.
>За счет них набирается ~30% дискового пространства.

Ну во-первых, появление избыточности - вполне естественная обратная сторона увеличения надёжности..
А во-вторых, насчёт 30% ты явно перегнул.. Хотя, это вполне возможно, если у тебя вместо нормального ёмкого винта стоит древний кирпич на 40 МБ..

>Дык тест там весьма малореалистичный. Как правило, чтение/запись
>идет на один раздел, причем этим одновременно занимаются
>несколько процессов.

Да ты, батенька, скептик.. :)

*************************************************************
Свои бенчмарки [делались на одной машине и на одном харде на разных Primary-партишенах]

>Попробуйте вот это:
>time dd if=/dev/zero of=test.1 bs=1M count=2048

Попробовал на EXT3 [block-size файловой системы = 4096 байт]

shell# mkfs.ext3 -V
Using EXT2FS Library version 1.34

shell# time dd if=/dev/zero of=/test bs=1M count=1024
1024+0 records in
1024+0 records out

real 0m21.846s
user 0m0.008s
sys 0m9.670s

**************************************************************
а теперь на ReiserFS [block-size файловой системы тоже = 4096 байт]

shell# mkreiserfs -V
mkreiserfs 3.6.11 (2003 www.namesys.com)

shell# time dd if=/dev/zero of=/mnt/hdc1/test.1 bs=1M count=1024
1024+0 records in
1024+0 records out

real 0m34.305s
user 0m0.012s
sys 0m6.955s
**************************************************************

DSelect, при всём уважении к твоей квалификации, ты слишком много болтаешь.

ту ДСелект:

>> А какая на твой взгляд фс может помочь в этом случае?

>Никакая, о том и речь -- журналирование данных БЕСПОЛЕЗНО. Потому
>его и нет ни в одной нормальной ФС, и только пЫонеры пытаются
>поднять себя за волосы...

Что-то мне подсказывает, что и ReiserFS тебе на фиг не нужен.. в лучшем случае EXT2..

ОО!! А может ты на NTFS насмотрелся?
Там, говорят, есть что-то типа журналирования, но я, честно говоря, думаю, что это - гонево.. Ибо столько раз инфа с NTFS высыпалась в утиль, что я не выдержал и переехал в линух.. :) а до тех пор так же, как и ты, считал журналирование дурацким мифом.. :)

> А во-вторых, насчёт 30% ты явно перегнул.. Хотя, это вполне возможно, если у тебя

... в /usr/include полно всякого добра...

> Свои бенчмарки [делались на одной машине и на одном харде на разных Primary-партишенах]

Вы не до конца сделали...

Цель теста -- показать, что ext3... употребляет чупа-чупс, если происходит одновременно чтение и запись двух больших файлов. Большие файлы берутся для того, чтоб тестировать именно производительность ФС, а не block cache; аналогичный результат был бы и при большом количестве среднего размера файлов ( если суммарный объем превышает раза в ~ 3 общий объем кеша). Сравнивается время записи файла в "ненагруженную" ФС и время записи _такого же_ файла, при одновременном чтении другого большого файла.

Понятное дело, что у любой ФС производительность во втором случае будет меньше, вопрос только в том -- на сколько. Я сравнивал XFS, ReiserFS и ext3 data=ordered. Сильнее всего производительность падает у ext3, из чего вывод: ext3 -- г...

> Что-то мне подсказывает, что и ReiserFS тебе на фиг не нужен..

Для моих потребностей лучше всего подходит XFS, но для /var таки лучше ReiserFS.

> в лучшем случае EXT2

fsck на разделе > 40Gb -- это больно...

> А может ты на NTFS насмотрелся? Там, говорят, есть что-то типа журналирования

Да, у NTFS есть журналирование. Одна из первых ФС, где оно появилось.

> Ибо столько раз инфа с NTFS высыпалась в утиль

Это как? Молотком по системному блоку? :)

> а до тех пор так же, как и ты, считал журналирование дурацким мифом.. :)

Журналирование _данных_ и есть дурацкое занятие. См. пример с tar'-ом.

с поставленными задачами. тормозов в работе заметно не было. журналируемость несколько раз выручала. что еще надо? тормоза существуют в вашем воображении. реальные задачи это не маркетинговые тесты заинтересованных сторон

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

нет. из этого следует что ты красноглазик подводящий идеологический базис под свои предпочтения :)

> нет. из этого следует что ты красноглазик подводящий идеологический базис под свои предпочтения :)

Когда нечем возразить на факты, переходят на личности.

>> Свои бенчмарки [делались на одной машине и на одном харде на
>>разных Primary-партишенах]

> Вы не до конца сделали...

угу, сорри..

shell# time (cat test.1 >/dev/null & dd if=/dev/zero of=test.2 bs=1M count=1024)

только сообщает о том, что операция прошла [типа 1024 записи сделано].. про время выполнения ничего не говорит..

честно говоря, я озадачен, чем бы померять время.. [секундомер не предлагать.. :)]

> только сообщает о том, что операция прошла [типа 1024 записи сделано]..

Как же так -- не говорит? Говорит:

real 0m21.846s

user 0m0.008s

sys 0m9.670s

> Никакая, о том и речь -- журналирование данных БЕСПОЛЕЗНО.

Лоботомия. Больше ничего товарисчу не поможет.

>Как же так -- не говорит? Говорит:

shell# time dd if=/dev/zero of=/test bs=1M count=1024
говорит..

а
shell# time (cat test.1 >/dev/null & dd if=/dev/zero of=test.2 bs=1M count=1024)

не говорит..

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

$ time /bin/bash -c "cat test.1 >/dev/null & dd if=/dev/zero of=test.2 bs=1M count=2048"

2048+0 records in
2048+0 records out
2147483648 bytes transferred in 61,608819 seconds (34856757 bytes/sec)

real 1m1.641s
user 0m0.030s
sys 0m4.800s

> журналируемость придумали и развивают

Ни в одной нормальной _журналируемой_ ФС -- XFS, UFS, ReiserFS, JFS, NTFS, etc -- нет такой мути, как журналирование данных. Потому, что их придумали и написали грамотные люди, а не начитавшиеся сказок про JBD красноглазые.

А почему у "грамотных" людей баг на баге и всё под маркой "экспериментал",
а продукт неграмотных стоит на большинстве рабочих систем?
Тебе не кажется, что ты перегрелся?

> $ time /bin/bash -c "cat test.

Один полезный результат этой дискуссии: Dselect научился писать
почти без ошибок простенькие скрипты на bash'е ;)

Кстати, а зачем там bash? Просто sh не подходит?

> а продукт неграмотных стоит на большинстве рабочих систем?

NTFS делали грамотные люди.

> NTFS делали грамотные люди

А чего тогда такие тормоза получились? Reiser вона летает, а эта NTFS неторопливо ползает, злобно похрумкивая диском.

> А чего тогда такие тормоза получились?

У нее куча tunables, только по умолчанию они уж слишком дуракоустойчивые...

> Кстати, а зачем там bash? Просто sh не подходит?

$ ls -l /bin/sh

lrwxrwxrwx 1 root root 4 Feb 24 23:32 /bin/sh -> bash*

> $ ls -l /bin/sh

А я думал с умным человеком разговориваю, который просто заблуждается.
А он совсем нулевой пионер. А ещё утверждал, что солярис на картинке
видел ;)

про пЫонеров.

> uname -rms

SunOS 5.9 sun4u

> uptime

12:46pm up 61 day(s), 15:42, 2 users, load average: 7.19, 7.17, 7.07

Куда там еще эти дурацкие тесты пускать...

journal на другом винте

btw, может кому поможет:
mke2fs -J device=/dev/hde7 /dev/hda5
поместило журнал на другом винте - увеличивает скорость работы и может быть повысит надёжность.
рецепт отсюда: http://www.zip.com.au/~akpm/linux/ext3/ext3-usage.html