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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.