LINUX.ORG.RU
ФорумTalks

[ЖЖ] ext3?

 


0

0

[ 8.863337] EXT3-fs: hda5: 263 orphan inodes deleted
[ 8.863337] EXT3-fs: recovery complete.

гектара торрентов уже не досчитался. что там еще отвалилось - я не нашел, но это "супернадежная" ФС?

на втором винте появились бэды…

Ответ на: комментарий от vgudkov

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

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

anonymous
()

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

PS

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

PPS

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

Shaman007 ★★★★★
()
Ответ на: комментарий от DNA_Seq

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

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

Shaman007 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

vgudkov
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от vgudkov

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

anonymous
()
Ответ на: комментарий от vgudkov

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

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

anonymous
()
Ответ на: комментарий от vgudkov

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от Evgueni

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

Увы, нет.

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

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

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

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

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

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

...

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

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.