[ЖЖ] ext3?

>Ты мерял умник?

Тратить время на опровержение этой очевидной ГСМ'щины у меня нет желания, т.к. никто из вас ее еще не доказал реальными цифрами и тестами

Скорее всего проблема в железе.

PS

Супернадежная она считается потому, что это единственная пока ФС, учитывающая факт того, что PC hardware sucks. Raiser3 у них для важных данных, ха-ха.

PPS

Что у вас за железо такое? Потраттье в следующий раз на 10 долларов больше, купите нормальный блок питания и матплату. Вон, комп родителям оставил, скоро 5 лет работы 24х7 и еще столько же проработает.

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

Образец не подкреплённого ничем, но популярного мнения. Как вы сравнивали с NTFS? Как вообще мерили надежность?

> На многопоточные ОС фрагментация сказывается только хуже. Уже не один поток будет дёргаться головами по диску, а несколько, конкурируя друг с другом. А если тут ещё учесть ту же популярность Сигейтов Барракуд, которые сами по себе в полную ж. уходят на паралелльных чтениях...

Если мы имеем 300 файлов две трети из которых открыты на произвольный доступ и 40 процессов. С учетом того, что контекст переключается независящим от процесса способом, имеется гипервизор в виде драйвера фаловой системы + фаловая система журналируемая т.е требует сброса журнала на диск и запись на диск буферизуется очень сомнительно, что файловая система без фрагментации потребует меньшего количества перемещений головки. А уж всякие win95 шаманства в виде размещения файла подкачки на начальных секторах вообще смешны.

>Это у тебя неправильные шутки! :)
Это тонкий йумор :-)

C фрагментацией про пользу от readahead можно забыть, и тем более: она увеличивает количество метаданных на extent-based ФС - что ни при каком раскладе не может способствовать ускорению работы с ФС. Так что твое выкладки о пользе фрагментации - всего лишь красивые сказки.

> Так что твое выкладки о пользе фрагментации - всего лишь красивые сказки.

А кто-то говорил про пользу?

>А кто-то говорил про пользу?

Ну да, это меня повело :) Но все равно: фрагментация вредна (особенно на современных ФС) и прикрыть это какими-либо факторами довольно сложно

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

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

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

В-третьих, есть практика. И в этой теме уже упоминали. Нередко проведение дефрагментации делает просто чудо в плане быстродействия. И совершенно измеримое. Скажем, emerge -auvDN world в Gentoo после дефрагментации может начать работать до трёх(!) раз быстрее. И под Windows та же фигня. Хотя там и проверять проще, ибо есть нормальный софт по дефрагментации, которого под Linux нет.

> Хотя там и проверять проще, ибо есть нормальный софт по дефрагментации, которого под Linux нет.

Чем вас tar или cp не устраивает? IMHO, это быстрее чем speedisk на тех же объёмах будет.

>Чем вас tar или cp не устраивает?

Тем, что неудобно дефрагментировать 400Гб видео, например.

>IMHO, это быстрее чем speedisk на тех же объёмах будет.

Ну ты вспомнил... Speedidk уже скоро 10 лет, как не работает.

Я про тоже. Он бы удавился на таком видио. Просто cp на соседний диск быстрее будет.

>Просто cp на соседний диск быстрее будет.

Увы, нет.

Во-первых, свободного диска на несколько сот гиг обычно просто не бывает.

Во-вторых, тот же PerfectDisk под офтопиком прекрасно работает во время бездействия машины и/или при показе скринсейвера. Т.о. дефрагментация для пользователя вообще прозрачно проходит. Ну и при регулярном и умном дефраге (с группировкой по времени доступа) она времени совсем мало занимает.

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

>Я вот не очень в курсе этих технологий "улучшения". Проверка скорости работы после дефрагментации делается, естественно, после обязательного сброса кэша?

Э... С технологиями - всё просто. Дефрагментация файлов и _обязательно_ - свободного пространства.

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

Наиболее ярко это заметно в играх с равномерной подгрузкой. Летишь в том же Lock On летишь, вдруг дырк винчестер... И на полсекунды машина висит. Потом летит дальше ещё десяток-другой километров.

После дефрагментации подобное поведение исчезает полностью.

...

Ну а точных тестов - никто не проводил. Слишком сложные условия. Вот на фрагментируемость разных ФС - это я проводил. В принципе, можно и усложнить. Провести искуственную фрегментацию, отбенчить, потом дефраг - и снова отбенчить. Но на это уже моего терпения не хватит. Итак на 50Гб-тесты по полчаса на одну FS уходило. А, ведь, ещё серии делать надо, чтобы результат был репрезентативен...