LINUX.ORG.RU
ФорумTalks

Дефрагментирование - мифы и реальность


0

0

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

anonymous

Это хорошо

anonymous
()

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

аЙ-я-яй. Сейчас тебя пинать начнут.

> Нужна ли она? Была ли нужна раньше?

Если раздел не заполняешь под 100%, то фрагментация файлов принебрежимо мала.

2ALL: Вот у меня другой вопрос по теме: в ktorrent можно задействовать функцию резервирования места перед закачкой, что вызовет обоснованную задержку перед началом загрузки. Если я там галочку не поставлю, фрагментация [семи]гигового файла на ext3 всё-таки будет или же нет?

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

фрагментация будет. Причём немаленькая. Я смотрел содержимое диска магнитным искателем, скажу, что фрагментация среднестатистического винчестера большая - про то что дефрагментация не нужна - миф.

anonymous
()

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

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

Legioner ★★★★★
()

По личным наблюдениям фрагментация сильно зависит от типа использования FS. Например на файло-помойке (jfs 250Гб), куда файлы закачивались в несколько потоков и много сразу фрагментация достигала 20k кусков на один файл. А на /usr за год эксплуатации фрагментации почти не появилось , хотя система обновлялась регулярно.

Crocodille
()

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

как-то так.

mirage
()

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

anonymous
()

> В EXT4 появится возможность возможность делать дефрагментацию файловой системы.

Что-то поздно, уже появился zfs.

> В связи с этим вопрос - миф или реальность насущная проблема дефрагментации?

Реальность.

> Нужна ли она?

Да.

> Была ли нужна раньше?

Да.

> Почему не была реализована?

Фанатизм и слепая вера.

> Зачем появилась в новой версии?

Раньше был проприетарный от O&O.

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

тупо сделать mkXXXfs — исчезнет ещё и проблема «где взять свободный раздел».

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

> поэтому фрагментация не важна

На твои мизерных объемах информации? Возможно.

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

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

улыбнуло. Интересно, что с хардлинками будет?

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

Да не, это вполне нормальный способ - дефрагментация через tar.
Главное, она работает :)

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

С фрагментацией разумно бороться разумными способами, сводя ее к минимальному necessary evil. И какую цель преследует дефрагментация? Например, нужно ли дефрагментировать 4Gb ISO образ дивидифильма? Конечно нет. Дефрагментировать файлы системы и программ? Тогда лучше пойти по модному нынче пути запуска с флешки.

У меня закачки разнообразных торрентов и мулов и каталог temp лежат на выделенном NTFS разделе 60Гб. Свободно 3Гб, фрагментированных файлов 59%. Когда свободно было 20Гб, я его дефрагментировал, с тех пор не трогал. При 5% дождаться конца дефрагментации нереально, да и смысл дефрагментировать temp каталог? Сам Windows вместе с Programs живут на C:, фрагментированных файлов 3%, а чему там фрагментироваться? Под linux с этим я слышал еще конкретнее, сразу назначается раздел swap, temp, bin, и user, из которых фрагментируются только user и temp

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

>Под linux с этим я слышал еще конкретнее, сразу назначается раздел swap, temp, bin, и user, из которых фрагментируются только user и temp
иногда лучше молчать))

grimp3ur
()
Ответ на: комментарий от Deleted

Ну толко с Винды человек, Filesystem Hierarchy Standard еще не осилил. А вы сразу накинулись. Не хорошо.

anonymous
()

Проблемы появляются при очень малом кол-ве свободного пространства на разделе. ФС типа ext3 практически не подвержены фрагментации.

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

>Ты откуда такое чудо выползло?

С венды. А почему чюдо? Ты что, dvd образы дефрагментируешь? Или по другим пунктам возражения есть?

anonymous
()

при дефрагментации и объединении внутренних и листовых узлов где-то в 2-2.5 раза сокращается время reiserfsck, скорость readdir не замерял, но первый вызов ldconfig выполняется тоже заметно быстрее, скорость чтения регулярных файлов не замерял, но она по идее тоже должна увеличиться

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

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

файлов, но не свободного места, и не факт, что каталоги будут дефрагментированы

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

> при дефрагментации и объединении внутренних и листовых узлов где-то в 2-2.5 раза сокращается время reiserfsck

сколько раз в год ты ребутишь компьютер ?)

phasma ★☆
()

А что касается ext4: экстентная запись компактней (в плане использования метаданных) по сравнению с ext3 лишь в том случае, когда мало фрагментов файла

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

>сколько раз в год ты ребутишь компьютер ?)

reiserfsk указан лишь для примера, т.к. он делает полный обход ФС и каталогов

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

> Например, нужно ли дефрагментировать 4Gb ISO образ дивидифильма?

нет, это оптический носитель, там принцип записи другой )

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

>нет, это оптический носитель, там принцип записи другой )

"Образ", чувствуешь в постинге слово "ISO образ"? Это 4гиговый файл обычно.

anonymous
()

> Дефрагментирование - мифы и реальность

А былины или сказания по дефрагментации есть?

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

>а нафига это? ты до сих пор ищешь find'ом с самого корня? O_o

нет, это я недогадливым намекаю на скорость работы stat и readdir: уж если и это для вас не показатель, тогда разговаривать тут нечего

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

и что оно должно мне показать? readdir вообще не показатель ничего -- кому в пень надо её постоянно дёргать по всему диску?

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

>кому в пень надо её постоянно дёргать по всему диску?

как раз в том, чтобы не дергать по всему диску, а читать последовательно =) так что разберись в себе, для начала

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

> совершенно пофигу. при большой рам всё, что нужно часто, живёт там.

А вот не соглашусь. У меня система со всеми делами даже гиг сожрать не может, если добавить второй он стоит просто пустой. При этом "дефрагментация через mv" даёт вполне ощутимый эффект, сравнимый с заменой обычного HDD на WD Raptor с 10000 об/мин. Так что про кэширование и раму имхо не туда... Это по-моему только Виста от нечего делать заранее кэширует весь диск по желанию левой пятки.

> время холодного старта пофигу (не каждые же 5 минут это происходит).

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

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

>У меня система со всеми делами даже гиг сожрать не может, если добавить второй он стоит просто пустой

Читаю ЛОР и слушаю небольшой плейлист. Через пару часов лампочка активности диска почти не мигает. ЧЯДНТ?

redgremlin ★★★★★
()

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

А вот фрагментация свободного пространства может сильно снижать скорость: http://www.linux.org.ru/view-message.jsp?msgid=2641133

Правда, боюсь, дефраг ext4 дефрагментирует только файлы, но не пространство.

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

>А вот фрагментация свободного пространства может сильно снижать скорость: http://www.linux.org.ru/view-message.jsp?msgid=2641133

reiserfs очень сильно фрамгентирует свободное пространство если заливать много (>1) файлов даже на пустой раздел, так что дело именно во фрагментации каталогов, а в ext3 каталог это тот же файл

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

> Читаю ЛОР и слушаю небольшой плейлист. Через пару часов лампочка активности диска почти не мигает. ЧЯДНТ?

Браузер с плеером сколько-нибудь большой объём сожрать не могут, об этом и речь. А вот первый запуск иногда очень противный бывает. В гномовском окружении запустите amarok или ktorrent. Никакой kdeinit не спасает, комп молча думает по минуте, потом шуршит хардом и только потом выдаёт этот самый амарок.

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

> reiserfs очень сильно фрамгентирует свободное пространство если заливать много (>1) файлов даже на пустой раздел, так что дело именно во фрагментации каталогов, а в ext3 каталог это тот же файл

Объясните мне кто-нибудь, почему в Убунте ext3 так тормозит? Рейзер летает, ставишь систему на ext3 - всё, привет... Никакие твики, флажки в /etc/fstab и т.д. не спасают. В слаке же разницы по скорости между ФС нет вообще никакой, всё одинаково быстро.

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

потому, что убунта это свалка по сравнению со слакой, а reiserfs при любых кондициях быстрее ext3 на операциях вроде stat() потому, что by design

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

ещё раз: зачем постоянно делать readdir? если ты не в курсе, то для открытия файла с конкретным именем в современных FS не надо сканировать весь каталог, пока не напорешься на нужное. также нормальные шеллы (zsh, например) кэшируют имена для автодополнения, так что и тут не надо постоянно дёргать readdir. таки мне ответят, за каким членом надо делать readdir постоянно? я вижу один вариант: автор софта, делающего такое, полный, неисправимый и мертворожденый дебил.

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

>ещё раз: зачем постоянно делать readdir? если ты не в курсе, то для открытия файла с конкретным именем в современных FS не надо сканировать весь каталог, пока не напорешься на нужное. также нормальные шеллы (zsh, например) кэшируют имена для автодополнения

не надо умничать, ты просто не вьезжаешь: readdir для получения содержимого всего каталога и тут shell-кеш совершенно ортогонален, учи матчасть и это зацикливание "делать readdir постоянно" упомянул лишь ты, так что сам разберись для начала со своими нелепыми претензиями

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

>не способный даже ответить по теме поста

какой вопрос - такой ответ

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