Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Alexey931, Вы писали:

A>>ext4 действительно не нуждается. Это свежее нововведение, да.

А>В 1 из споров с интеграторами у нас на работе сделали такой пример:

А>1. Раздел ext3 забивается файлами с мусором по 1Мб, пока не кончится свободное место.
А>2. Файлы транкаются до 512кб.
А>3. В получившемся свободном пространстве создается большой файлик, примерно 8Гб, чтобы исключить влияние кеша.
А>4. Меряется скорость чтения и перезаписи такого файла.

А>По невероятному стечению обстоятельств, скорость работы с файлом из п.3 сильно просажена (порядка 30-50%) по сравнению со скоростью работы с таким же файлом на свежесозданном разделе.
А>Ситуация устойчиво воспроизводилась несколько раз. Интеграторы рассказывали про фазы луны, неудачное расположение звезд, ещё что-то такое...
А>Рассказывали всё, кроме того, где можно взять дефрагментатор для ext3.

А>Система, правда была ext3, а не ext4, так вот, крайне интересно, какие средства ext4 позволяют избежать деградации скорости работы в подобной ситуации?

другой пример.
1. создаем каталог в ext3
2. забиваем 100000 файлов размером в чуть меньше блока
3. удаляем все добро
4. пустой каталог остается занимать чуть больше 3мб при размере блока 1кб
а по воле судьбы у нас приложение в день 50-200 раз пересоздает файл в каталоге, и делает это в разных каталогах численных которых около ста тысяч
деградация производительности ужасная, проход по всем этим каталогам одним find занимает пару часов на скази 146гб
когда становится совсем хдо приходится переливать на чистый диск

Здравствуйте, <Аноним>, Вы писали:

KDK>>Не допускать таких сценариев, что может быть проще. Если требуется автивная работа с кучей мелких файлов, то делаем отдельный раздел на эту задачу. Я именно так и делал. был отдельный раздел для кэша squid'а. размер его был размер кэша * 1.3
А>Хорошо, вот задача: необходим сторейж для разных данных, общий размер — 2Тб. Разные — это от документов ворда до образов виртуальных машин. С сторажем будет вестись активная работа, для простоты скажем, что отключать полностью на обслуживание нельзя совсем.
А>Ваши предложения по разбиению его на разделы, чтобы такие сценарии не повторились?
А>Ваши предложения, как объяснить пользователям, что файлы нужно размещать в папки по месту, которое они занимают на диске, а не логически?

Делаем сторадж на 3-4 TB, Ставим общую квоту на каталог, в котором будет вестись работа в 2TB. Вайжно понимать, что хранилище, это такой же русурс, как и остальные и при его исчерпании могут проявляться артефакты. Делаем же мы запас по процессору и по памяти, а при их исчерпании видим всякие проблемы с шедулерами, etc.

Здравствуйте, netch80, Вы писали:

N>>>Это что нужно курить,
J>>Можно как-то уровень хамства понизить? Спасибо.
N>Можно. Не искать "хамство" во всех проявлениях всего, что Вам лично не нравится, и не использовать его как ярлык на каждую ответную реплику, которая чуть менее чем "да-да, дорогая, я с тобой полностью согласна".
Я хамство вижу исключительно в используемых хамских формулировках и хамском тоне.
В прошлый раз у Вас было оправдание в виде дедлайна, в этот раз тоже?
Я уверен, что все Ваши несомненные обширные познания в юниксах можно излагать в корректных и вежливых выражениях, от этого их ценность не уменьшится.

J>>Ну замечательно. У тебя есть свои реалистичные соображения на этот счет (на любой из)? Поделись, плиз.

N>Мои соображения по этому поводу очень простые:
N>1. Собаки лают, а караван идёт. Это о любом развитии обсуждаемых явлений.
А конкретнее? Как именно идет и куда?

N>2. _Здесь_ лучше решать поднятые вопросы для себя лично и не раздувать флейм из роликов для полных носорогов.
Пока что раздуванием флейма занимаетесь тут Вы.

N>Засим настоятельно рекомендую переместить данную ветку не ближе СВ и не загрязнять полезные форумы.
Я сюда именно затем и запостил, что здесь не будет злопыхателей и апологетов винды, которые затеют соответствующий бессмысленный флейм, а будут конструктивные высказывания по всем озвученным проблемам (ну, кроме общих проблем опенсорса — они здесь офтопик). Либо в виде собственных соображений, либо в виде ссылок (типа "вот тут это обсуждалось, пришли к вот такому решению"). Пока что я ничего конструктивного не услышал.

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

Если ответ опять предполагается в хамском стиле и с отсутствием конкретики, то не отвечайте, пожалуйста.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, ilnar, Вы писали:

I>у нас админы например в продакшене вообще отрекаются от ufs и xfs )))

Этого не понимаю. Во-первых, у них несовместимые контексты — если, разумеется, речь не идёт о вариантах ZFS для FreeBSD и ext*/reiser/etc. для Linux, причём раздельно. Во-вторых, какой смысл "отрекаться" от них не учитывая контекст — когда, например, XFS под SuSE работает не хуже, чем ext3 под RH?

Здравствуйте, jazzer, Вы писали:

N>>Можно. Не искать "хамство" во всех проявлениях всего, что Вам лично не нравится, и не использовать его как ярлык на каждую ответную реплику, которая чуть менее чем "да-да, дорогая, я с тобой полностью согласна".
J>Я хамство вижу исключительно в используемых хамских формулировках и хамском тоне.

Ну если формулировку ещё можно поставить под сомнение, то Ваше предположение про тон, мягко говоря, субъективно. Я же со своей стороны не склонен употреблять данный термин, но, как для меня, подобное Вашему выдвижение неоправданных утверждений про собеседника в риторической форме, которая требует ответа в оправдывающихся формулировках, является тяжёлой формой хамства с Вашей стороны. Так что теперь я хочу послушать, чем Вы объясните то, что употребили формулировку, которая заставляет собеседника оправдываться, когда к этому не было никаких оснований в моих сообщениях.

N>>Засим настоятельно рекомендую переместить данную ветку не ближе СВ и не загрязнять полезные форумы.
J>Я сюда именно затем и запостил, что здесь не будет злопыхателей и апологетов винды, которые затеют соответствующий бессмысленный флейм, а будут конструктивные высказывания по всем озвученным проблемам (ну, кроме общих проблем опенсорса — они здесь офтопик). Либо в виде собственных соображений, либо в виде ссылок (типа "вот тут это обсуждалось, пришли к вот такому решению"). Пока что я ничего конструктивного не услышал.

Ничего иного при таком стиле вброса собственно и не ожидалось (да-да, я это намеренно называю "вброс", можете опять считать это хамством). Хотите конструктивного разговора — начните его с конструктивного предложения и конструктивных оценок. Для начала можно было бы выделить самостоятельно отдельные ключевые проблемы и рассмотреть их по отдельности. Более того, реальный конструктивный разговор мог бы начаться только в том случае, если бы Вы осветили проблему именно так, как она Вам интересна. Например, вопросы личного использования, в фирме какого-то профиля, etc. Поднимать же вопросы в форме "XXX sucks?" совершенно без учёта контекста и без разбора на отдельные аспекты, jIMHO, является бесспорной и грубой формой троллинга.

J>И лично я не вижу логики за высказыванием (как я его понял) "Любые системные проблемы юниксов должны обсуждаться не в юниксовом форуме, а в СВ", потому что в СВ тема тут же будет погребена под потоком бессмысленного флейма (впрочем, флейм в Вашем исполнении получается и здесь, так что, может, в отношении Вас Ваша рекомендация и верна).
J>Если ответ опять предполагается в хамском стиле и с отсутствием конкретики, то не отвечайте, пожалуйста.

Спасибо за предложение, но я им не воспользуюсь. В качестве встречных предложений у меня два, на выбор:
1. Прочитайте ссылку "Как правильно задавать вопросы" в форме постинга RSDN и примените её рекомендации на практике.
2. Игнорируйте мои реплики. Всё равно то, что я пишу здесь по сути, Вам явно не интересно.

Здравствуйте, Аноним, Вы писали:

N>>А вот это, BTW, крайне интересно. Делались ли у вас какие-то тесты подобного рода для других FS?
N>>В качестве "ключевых" интересуют UFS (лучше UFS2), так как у неё с рождения средства типа "фрагментируем заранее чтобы избежать тяжёлых форм фрагментации" (например, ни одному файлу не дают занять больше половины полосы), и XFS, как распространённая альтернатива ext3.

А>Нет, тестов не делали, впрочем описанный пример крайне прост для реализации, сделан вообще скриптом. Можете замерять на вашем реальном железе, или подправить по обстоятельствам.

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

N>>Судя по википедии — это
N>>1) выделение на файл крупных кусков (экстентов) пока позволяет суммарный объём FS. режим несовместим с ext3.
N>>2) преаллокация по запросу — если мы знаем, что нам придёт 100G одним куском, можем их занять заранее, и тогда оно значительно вероятнее не будет иметь проблем фрагментации.
N>>Сам всё это не пробовал, так что только теория.

А>И 1 и 2 хорошо работает, когда есть много непрерывного свободного места. Наш сценарий заведомо его фрагментировал. Даже в теории не вижу способа, как в него можно посадить большой файл без фрагментации...

Это понятно. Но, с другой стороны, данный случай является и практически крайним: таких шаблонов использования на практике не существует. При минимально нормальном администрировании есть достаточное количество свободного места для того, чтобы аллоцировать место кусками разумного размера.

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

Здравствуйте, ilnar, Вы писали:

I>другой пример.
I>1. создаем каталог в ext3
I>2. забиваем 100000 файлов размером в чуть меньше блока
I>3. удаляем все добро
I>4. пустой каталог остается занимать чуть больше 3мб при размере блока 1кб
I>а по воле судьбы у нас приложение в день 50-200 раз пересоздает файл в каталоге, и делает это в разных каталогах численных которых около ста тысяч
I>деградация производительности ужасная, проход по всем этим каталогам одним find занимает пару часов на скази 146гб
I>когда становится совсем хдо приходится переливать на чистый диск

Мнэээ... а можно вопрос, почему вы в этом случае используете именно FS? Такой метод работы крайне неудобен для любой файловой системы, а не только ext3.
Да, некоторые из них с этим значительно лучше справляются — проблема работы с такими каталогами возникает из-за того, что у ext3 плоские каталоги. Во многих достаточно новых FS каталоги организованы деревьями, там таких проблем нет.

В случае UFS, кстати, Вы могли спокойно нарваться в таком режиме ещё и на другую проблему — исчерпание инодов. По умолчанию сейчас заводится один инод на 8KB данных (на пол-блока при умолчательном блоке 16KB), а слишком мелкими файлами иноды истощатся ранее, чем закончится место на диске. А в случае NTFS, насколько я помню, такими файликами можно нарваться на переполнение MFT и паралич FS за счёт того, что она не умеет сокращать MFT.

Всё-таки эта задача значительно больше подходит для какой-нибудь средней DBMS вроде mysql, чем для FS...

Здравствуйте, KipDblK, Вы писали:

KDK>>>Не допускать таких сценариев, что может быть проще. Если требуется автивная работа с кучей мелких файлов, то делаем отдельный раздел на эту задачу. Я именно так и делал. был отдельный раздел для кэша squid'а. размер его был размер кэша * 1.3
А>>Хорошо, вот задача: необходим сторейж для разных данных, общий размер — 2Тб. Разные — это от документов ворда до образов виртуальных машин. С сторажем будет вестись активная работа, для простоты скажем, что отключать полностью на обслуживание нельзя совсем.
А>>Ваши предложения по разбиению его на разделы, чтобы такие сценарии не повторились?
А>>Ваши предложения, как объяснить пользователям, что файлы нужно размещать в папки по месту, которое они занимают на диске, а не логически?

KDK>Делаем сторадж на 3-4 TB, Ставим общую квоту на каталог, в котором будет вестись работа в 2TB. Вайжно понимать, что хранилище, это такой же русурс, как и остальные и при его исчерпании могут проявляться артефакты. Делаем же мы запас по процессору и по памяти, а при их исчерпании видим всякие проблемы с шедулерами, etc.

То есть, вместо того, чтобы иметь тулзу для онлайн дефрагментации, мы делаем запас в 100% вместо 10-15% и живем счастливо?

А где гарантия, что 3-4Тб хранилище не фрагментируется?

Здравствуйте, netch80, Вы писали:

N>OK, понятно. Я уже примерно догадываюсь, что тут скорее всего от FS мало что зависит — в крайнем случае будет чуть меньше фрагментов.

...

N>Это понятно. Но, с другой стороны, данный случай является и практически крайним: таких шаблонов использования на практике не существует. При минимально нормальном администрировании есть достаточное количество свободного места для того, чтобы аллоцировать место кусками разумного размера.

Пример, разумеется крайний. Он специально таким сделан. Вопрос в другом: адепты ext2-3-4 делают общее утверждение, что их ФС не фрагментируются, следовательно, дефрагментатор им не нужен.
Про строгое доказательство они, разумеется, даже говорить не готовы, но вот конкретный частный случай фрагментации, следовательно они уже не правы. Все замеры можно сделать меньше чем за час.
Что касается реальной жизни, то продлив срок жизни конкретной ФС с часа до 2-3 лет активного использования, я думаю, что может (может, а не обязательно получится) что-то похожее получится.

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

Причина в том, что не такое это и простое дело — онлайн дефрагментатор. Чуть сложнее, чем генту компилировать.

Здравствуйте, Аноним, Вы писали:


А>То есть, вместо того, чтобы иметь тулзу для онлайн дефрагментации, мы делаем запас в 100% вместо 10-15% и живем счастливо?

Какая из твоих любимых ФС не подверженна дефрагментации в приведённом тобой сценарии?

А>А где гарантия, что 3-4Тб хранилище не фрагментируется?

Ситуация, когда дисковое пространство заканчивается полностью — это очень редкое явление, и приводит оно к неработоспособности системы (зачастую).

Допустим, у вас есть хранилище, размером в 2ТБ и забитое на 90%. Фрагментированное. Как долго твой онлайн-дефрагментатор твоей любимой ФС это дефрагментировать? И насколько просядет работа со стореджем?

От того, что файл размером несколько МБ разбит на два-три фрагмента — ничего страшного нет. Потеря 5% производительности (или меньше) — это ничего страшного. Так как на диске скорость сильнее менятся от начала к концу пластин

Здравствуйте, netch80, Вы писали:

N>Мнэээ... а можно вопрос, почему вы в этом случае используете именно FS? Такой метод работы крайне неудобен для любой файловой системы, а не только ext3.
N>Да, некоторые из них с этим значительно лучше справляются — проблема работы с такими каталогами возникает из-за того, что у ext3 плоские каталоги. Во многих достаточно новых FS каталоги организованы деревьями, там таких проблем нет.

Как всегда, встает вопрос связи между приложениями. ФС — это 1 из самых простых способов (не всегда лучший или быстрый). Альтернатив много: MSMQ, WebSphere...

N>В случае UFS, кстати, Вы могли спокойно нарваться в таком режиме ещё и на другую проблему — исчерпание инодов. По умолчанию сейчас заводится один инод на 8KB данных (на пол-блока при умолчательном блоке 16KB), а слишком мелкими файлами иноды истощатся ранее, чем закончится место на диске. А в случае NTFS, насколько я помню, такими файликами можно нарваться на переполнение MFT и паралич FS за счёт того, что она не умеет сокращать MFT.

Не понял, что за переполнение MFT. Она вроде динамически растет и переиспользуется при необходимости. Какую-нибудь ссылку на описание можно?

N>Всё-таки эта задача значительно больше подходит для какой-нибудь средней DBMS вроде mysql, чем для FS...

С БД свои приколы могут быть. И сразу появляется необходимость в хорошем DBA.

Здравствуйте, Аноним, Вы писали:

А>Хорошо, вот задача: необходим сторейж для разных данных, общий размер — 2Тб. Разные — это от документов ворда до образов виртуальных машин. С сторажем будет вестись активная работа, для простоты скажем, что отключать полностью на обслуживание нельзя совсем.
Обычный ext4, можно XFS. На практике проблем с фрагментацией не возникает.

Здравствуйте, Аноним, Вы писали:

А>Какая из твоих любимых ФС не подверженна дефрагментации в приведённом тобой сценарии?

А вот не надо передергивать. Я не писал, что какая-то система не фрагментируется. Я писал, что у ext3 нет онлайн дефрагментатора.
Предвосхищая вопрос, где он есть — отвечаю: NTFS.

А>Ситуация, когда дисковое пространство заканчивается полностью — это очень редкое явление, и приводит оно к неработоспособности системы (зачастую).

Угу, опять передергиваем. Свободное место есть, оно просто фрагментировано.

А>Допустим, у вас есть хранилище, размером в 2ТБ и забитое на 90%. Фрагментированное. Как долго твой онлайн-дефрагментатор твоей любимой ФС это дефрагментировать? И насколько просядет работа со стореджем?

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

А>От того, что файл размером несколько МБ разбит на два-три фрагмента — ничего страшного нет. Потеря 5% производительности (или меньше) — это ничего страшного. Так как на диске скорость сильнее менятся от начала к концу пластин

Если бы 5%, то никто бы и не беспокоился. Я же писал, что тесты показывают от 30% до 50%.

Здравствуйте, Аноним, Вы писали:

А>То есть, вместо того, чтобы иметь тулзу для онлайн дефрагментации, мы делаем запас в 100% вместо 10-15% и живем счастливо?
Не 100%, достаточно где-то процентов 10-15%.

А>А где гарантия, что 3-4Тб хранилище не фрагментируется?
Ну так на практике не фрагментируется. А если фрагментируется, то это уже может быть поводом взять какую-нибудь БД.

Поэтому онлайновых дефрагментаторов и нет до сих пор — всем лень их делать.

Здравствуйте, Cyberax, Вы писали:

C>Обычный ext4, можно XFS. На практике проблем с фрагментацией не возникает.

Гм, как бы ещё попроще объяснить. Работающий пример, показывает что производительность заметно просаживается. Куда ближе к практике, от голой теории (что дефрагментировать не надо) прийти, я не знаю.

Или говоря, "На практике" вы имеете в виду, что:

1. Вы сами не меряли;
2. Вас и имеющаяся производительность устраивает;

???

Здравствуйте, Аноним, Вы писали:

А>Пример, разумеется крайний. Он специально таким сделан. Вопрос в другом: адепты ext2-3-4 делают общее утверждение, что их ФС не фрагментируются, следовательно, дефрагментатор им не нужен.
Так искусственные примеры никому особо не интересны. Интересна практика, а она показывает, что дефрагментатор таки, действительно, не нужен.

Ну давай я тебе приведу свой крайний пример — вот у нас есть КрутаяФС с онлайн-дефрагментатором. Она используется в качестве файл-сервера, держит 10000 запросов в секунду. И вдруг БАЦ! и включается дефрагментатор, и количество запросов уменьшается а 3 раза (примерно так с NTFS ситуация обстоит). И работа предприятия останавливается. И чтобы такого не произошло, нужно трёхкратное резервирование по скорости. Упс.

Здравствуйте, Cyberax, Вы писали:

C>Так искусственные примеры никому особо не интересны. Интересна практика, а она показывает, что дефрагментатор таки, действительно, не нужен.

Так наглядно покажите, что не нужен. Вот только как?

C>Ну давай я тебе приведу свой крайний пример — вот у нас есть КрутаяФС с онлайн-дефрагментатором. Она используется в качестве файл-сервера, держит 10000 запросов в секунду. И вдруг БАЦ! и включается дефрагментатор, и количество запросов уменьшается а 3 раза (примерно так с NTFS ситуация обстоит). И работа предприятия останавливается. И чтобы такого не произошло, нужно трёхкратное резервирование по скорости. Упс.

Угу. Если 10000 запросов/с в каждую из 86400 секунду, то тогда нам нужно резервирование по скорости. Может и 3х-кратное. А если есть часик другой, когда этих запросов 10-100 в секунду, то можно жить. Логично?

Здравствуйте, Аноним, Вы писали:

N>>Это понятно. Но, с другой стороны, данный случай является и практически крайним: таких шаблонов использования на практике не существует. При минимально нормальном администрировании есть достаточное количество свободного места для того, чтобы аллоцировать место кусками разумного размера.
А>Пример, разумеется крайний. Он специально таким сделан. Вопрос в другом: адепты ext2-3-4 делают общее утверждение, что их ФС не фрагментируются, следовательно, дефрагментатор им не нужен.

Адепты — какие? Если фанатики, так на то они и фанатики, чтобы гнать пургу. Более-менее реальный подход здесь — что практически фрагментация, конечно, есть (как я уже говорил, UFS драйвер в *BSD её делает специально, чтобы файлы не занимали целые полосы) — но реальное её влияние в реальных задачах слишком мало, чтобы мешать работе. В какой-то мере это справедливо для любой современной FS (фрагментация для NTFS нужна значительно меньше, чем для FAT), но в случае Windows нельзя было не писать дефрагментатор хотя бы потому, что иначе закидали бы помидорами.:)

Реальный уровень дефраментации меряет, например, fsck — на моих шаблонах применения он не выходит за 15%, и этого IMHO достаточно, чтобы не думать о том, что надо вмешиваться.

Ещё один фактор — а когда собственно мы будем делать дефрагментацию? На Unix системе значительно более было вероятно (до последних нескольких лет) что она работает 24*7, и дефрагментатор должен быть адекватно сращен с драйвером FS, чтобы ему никак не мешать. Исполнения для Windows, сколько я их видел, в лучшем случае делают частичный перезапуск по чужому вмешательству.

А>Про строгое доказательство они, разумеется, даже говорить не готовы, но вот конкретный частный случай фрагментации, следовательно они уже не правы. Все замеры можно сделать меньше чем за час.

Можно. И опять-таки — нужно ли? Я могу загнать систему в ещё более извращённую позу, но на реальной осмысленной практике такое не получится.

А>Что касается реальной жизни, то продлив срок жизни конкретной ФС с часа до 2-3 лет активного использования, я думаю, что может (может, а не обязательно получится) что-то похожее получится.

В том и дело, что не получается. у меня некоторые FS по 5-7 лет жили, без подобных последствий.

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

А>Причина в том, что не такое это и простое дело — онлайн дефрагментатор. Чуть сложнее, чем генту компилировать. ;)

О! вот и возникает вопрос о смысле организации доступа парнокопытного травоядного, ведущего род из горной местности, к музыкальному инструменту семейства язычковых.

Здравствуйте, netch80,

Тут есть 1 небольшой ньюанс: надо или нет, чтобы система выдавала возможный максимум.

Если да, то приходится заботится о всяких разных моментах. Поверьте, вопрос про фрагментацию ФС был далеко не единственным, от которого интеграторы шипели и плевались....

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

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, ilnar, Вы писали:

I>>другой пример.
I>>1. создаем каталог в ext3
I>>2. забиваем 100000 файлов размером в чуть меньше блока
I>>3. удаляем все добро
I>>4. пустой каталог остается занимать чуть больше 3мб при размере блока 1кб
I>>а по воле судьбы у нас приложение в день 50-200 раз пересоздает файл в каталоге, и делает это в разных каталогах численных которых около ста тысяч
I>>деградация производительности ужасная, проход по всем этим каталогам одним find занимает пару часов на скази 146гб
I>>когда становится совсем хдо приходится переливать на чистый диск

N>Мнэээ... а можно вопрос, почему вы в этом случае используете именно FS? Такой метод работы крайне неудобен для любой файловой системы, а не только ext3.
N>Да, некоторые из них с этим значительно лучше справляются — проблема работы с такими каталогами возникает из-за того, что у ext3 плоские каталоги. Во многих достаточно новых FS каталоги организованы деревьями, там таких проблем нет.

N>В случае UFS, кстати, Вы могли спокойно нарваться в таком режиме ещё и на другую проблему — исчерпание инодов. По умолчанию сейчас заводится один инод на 8KB данных (на пол-блока при умолчательном блоке 16KB), а слишком мелкими файлами иноды истощатся ранее, чем закончится место на диске. А в случае NTFS, насколько я помню, такими файликами можно нарваться на переполнение MFT и паралич FS за счёт того, что она не умеет сокращать MFT.

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

N>Всё-таки эта задача значительно больше подходит для какой-нибудь средней DBMS вроде mysql, чем для FS...

приму к сведению, но без пробы тут ничего не скажешь. файлы могут быть как большими, так и маленькими. и чем поможет использование блобов в субд взамен ФС? надо изучать, всетаки есть много другой специфики