Почему в Linux не нужна дефрагментация
Пользователи, которым посчастливилось избавиться от рабства Windows и перейти на свободный Линукс, часто удивляются, узнав, что в Линуксе нет программы дефрагментации диска. Как же так? Чем дефрагментировать?
Ответ заключается в том, что в случае Линукса, операционная система работает на пользователя, а не пользователь обслуживает операционную систему. Файловая система Линукса не нуждается в дефрагментации, борясь с этим неприятным явлением самостоятельно. Авторы заметки «HTG Explains: Why Linux Doesn’t Need Defragmenting» объясняют почему так произошло. Если кратко, то суть статьи можно свести к следующему.
В FAT каждый новый файл размещается, по возможности, как можно ближе к началу диска и следует вплотную за другими файлами. Когда размер одного из файлов изменяется в сторону увеличения, следующий за этим файлом препятствует изменению размера и операционной системе приходится разбивать редактируемый файл на фрагменты.
В NTFS разработчики решили поступить чуть умнее, оставляя вокруг каждого файла "буферную зону" из свободного пространства, которое затем может использоваться, если объем файла увеличится. Иногда такой метод работает, иногда нет, но в итоге пользователю все равно приходится проводить дефрагментацию, чтобы вернуть прежнюю производительность.
Разработчики Линукса решили проблему фрагментации, причем сделали это простым и изящным способом. В файловых системах Ext2, Ext3 и Ext4 новые файлы равномерно "раскидываются" по всему диску. При увеличении объема файла используется все доступное свободное пространство между файлами и фрагментации, в большинстве случаев, не происходит. А если она все же и происходит, то файловая система в фоновом режиме старается переносить дефрагментированные файлы в другое место, где фрагменты могут быть объединены. Таким образом, отдельные и регулярные процедуры дефрагментации не требуется.
Кстати, с таким фоновым переносом фрагментов файлов связана одна интересная особенность файловых систем Ext. Если диск заполнен более чем на 95% (80% по другим данным), то фрагментация все же возможна. Чтобы предупредить снижение скорости чтения и записи файлов в этом случае следует задуматься о покупке нового, более просторного диска. Если этот вариант не для вас, то существует одна хитрость, позволяющая избавиться от фрагментации даже в случае переполненного диска. Перепишите все файлы фрагментированного раздела в другой раздел, а потом скопируйте обратно. Файловая система сама более разумно разместит вновь записываемые файлы, что позволит избавиться от фрагментации.
Комментарии
Чингачгук
5 июня, 2012 - 07:36
Всё ОК. На ext4 проверял. Но это срамота:
> Перепишите все файлы фрагментированного раздела в другой раздел, а потом скопируйте обратно.
comrade
5 июня, 2012 - 11:08
Да уж, из предыдущего содержания следует другой совет – не засирать системный диск больше чем на 80%, только и всего!
((-:
MrBison
5 июня, 2012 - 11:26
>> А если она все же и происходит, то файловая система в фоновом режиме старается переносить дефрагментированные файлы в другое место, где фрагменты могут быть объединены. Таким образом, отдельные и регулярные процедуры дефрагментации не требуется.
Кстати, в Windows ещё со времён XP, если компьютер простаивает в течение 5 минут, то запускается фоновая дефрагментация.
Увы, но тут-то как раз нас и бьёт разнообразие файловых систем. Если ext4 и умеет автоматически (как и вручную через e4defrag) дефрагментироваться, то, например, ReiserFS (даже в 4 версии) этого не умеет. Как и более старые версии ext2/3.
=================================================
А полноценная графическая программа, которая хотя бы работала бы как интерфейс к дефрагментаторам различных ФС, всё равно не помешала бы.
Чингачгук
5 июня, 2012 - 12:12
>Файловая система Линукса не нуждается в дефрагментации
>файловая система в фоновом режиме старается переносить дефрагментированные файлы в другое место
у меня парсер сломался. файловая система не нуждается в дефрагментации, но фрагментированные (да, именно ФРАГМЕНТИРОВАННЫЕ - от слова "фрагмент") файлы в ней появляются
MrBison
5 июня, 2012 - 12:57
Имеется в виду, что Ext4 значительно меньше подвержена фрагментации, чем FAT и NTFS, и даже в случае её появления предусмотрено автоматическое от неё избавление.
pomodor
5 июня, 2012 - 17:20
Трудно, наверное, жить с таким болезненным парсером? ;) Вот Вам еще "разрыв шаблона": на диске часто появляются сбойные сектора, но несмотря на слово "сбойный" их появление... о чудо... не приводит к сбою, т.к. битые сектора незаметно для юзера подменяются на целые в запасной области (на физическом уровне) или помечаются как неиспользуемые на уровне файловой системы.
Чингачгук
6 июня, 2012 - 00:20
ntfs давно устарела по своим потребительским свойствам (ужасно тормозит на маленьких файлах, требует периодической штатной дефрагментации), но и в e2fsprogs появилась такая программка, как e4defrag :) Не зря, видимо. А в xfs она изначальна была, jfs подвержена ей почти также, как ntfs (корни-то одни), в btrfs-utils тоже есть программа для дефрагментации. В общем, при активной работе с файлами любая ФС загадится, другое дело, что с ext4 это произойдет гораздо позже, чем в винде, и тогда придется или запускать дефрагментатор, или копировать на другой винт, что частенько советуют в разных книгах и статьях по линюкс - согласитесь, совет из разряда нелепых, поэтому с появлением штатной утилиты для ext4 он наконец-то ушел в небытие. Но говорить о том, что в линюкс дефргаментации нет, - в корне не верно. Есть она, но по сравнению с виндой она является почти не значительным явлением и значительно более труднодостижима при одних и тех же рабочих условиях.
Чингачгук
10 сентября, 2013 - 07:12
В ext4 и ext3 тоже, если мне не изменяет память, часть раздела резервируется. Это примерно 10%. Даже если заполнить диск на 100%, вдруг окажется, что лишние мегабайты как-то записались. потом, конечно, всё равно придётся место освобождать, но возможно эти самые 10% и позволяют в фоне проводить дефрагментацию.
Чингачгук
23 января, 2014 - 12:46
Избавьтесь от рабства механических дисков — купите SSD и забудьте про дефрагментацию, тормоза, начало и конец диска, и дурацкие споры о том кто круче :)
pomodor
23 января, 2014 - 13:22
Так дороговато пока. Из рабства механических дисков можно уйти лишь в финансовое рабство производителей SSD. Хотя не спорю, SSD — штука прекрасная и сам планирую начать активно пользоваться технологией. Как только цена упадет до тысяч трех за 512 Гб модель. ;)
Чингачгук
23 января, 2014 - 13:03
Абсолютная нелогичность утверждений заключается в их категоричности. Простое опровержение этого мифа: запишите на 100гиговый диск 1000 мелких файлов, предположим система их равномерно распределила по 10 на 1 гиг, а теперь пробуем записать 1гиг одним файлом поверх равномерно рассыпаных мелких файлов — сдаётся мне, что без фрагментации тут не обойдётся, либо будет нужна какая-то подготовка к записи большого куска — по сути, динамическая дефрагментация.
pomodor
23 января, 2014 - 13:26
Кстати, интересный случай. Какое решение будет более быстрым: разделить на куски большой файл или предварительно перенести мелкие в одну кучу.
Чингачгук
10 июня, 2017 - 12:49
Разделить файл можно быстро, таблица же есть. А над переносом мелких в одно место надо вычсления производить, искать по таблице, то дрефраглер и делает.
В Линукс фрагментация идет с самого начала (из-за "защиты" от сбоев, которая отчасти есть и в NTFS). Здесь же любой файл, когда пишется, изначально разбивается на множество кусочков по 200 Кб (хотя да, сначала они идут последовательно). Между кусочками какая-то служебная информация (байты #01,#00... по один и два кило длиной). Если работать с Линукс как и с виндой, то очень скоро система начинает тупить. Дефрагментатор не помешал бы.
Vladimir_d
23 июля, 2020 - 14:06
Дефрагментация имеет смысл, если вы собираетесь с максимальной скоростью прочитать огромный файл. В реальных же условиях нужно понимать, как работает ОС с диском. При загрузке ОС или программ, в память загружается чудовищное количество файлов. Никакого смысла нет в том, что каждый файл дефрагментирован, если все они раскиданы равномерно по всему диску. В ext2,3,4, как я где-то читал (не могу вспомнить), раздел диска разбивается на некоторые участки, файлы, лежащие в одной папке записываются в один такой участок, записываются они чанками по несколько мегабайт. Т.е. файл уже изначально разбивается на чанки, если он слишком большой и нет места целиком его записать. Таким образом при запуске системы или запуске одной программы, все фрагменты файлов имеют достаточно большой размер и лежат в одной области диска с целью уменьшения расстояния для перемещения головки. Вот поэтому в линукс фрагментация и не влияет на производительность.
Если речь идёт о большой базе данных, главное, чтобы чанки файлов БД были расположены на диске близко, т.к. всё равно данные из БД не извлекаются последовательно. Т.е. и здесь фрагментация не влияет на производительность.
Ну а в этоху ССД дефрагментация вообще не имеет смысла, т.к. на ХДД лежат пользовательские данные, скорость чтения которых практически не имеет значения. Например, чтобы посмотреть двух часовой HD фильм 50 гигов, достаточно скорости около 8 мб/с.
Texnoline
24 июля, 2020 - 08:53
ну, вообще то, зависит: от битрейта, кодека и т.д..:) В случаи HD, возможно вы и правы, а вот если кодес с контейнером по забористей???Типа, всяких 4K/2К 60 кадров в секунду и выше, там скорости другие уже будут...
Vladimir_d
24 июля, 2020 - 10:24
Я как раз битрейт и вычислил из объёма и продолжительности. Ок, возьмём запредельный случай - 200 Гб и 1 час. Т.е. 204800 Мб и 3600 сек, делим, получаем 57 Мб/сек. Теперь примем, что он разбит на куски, скажем, по 32 Мб. На позиционирование головки, допустим, уходит 50 мс (специально завысил), тогда на чтение одного куска должно уходить максимум 32/57=0.56 сек, а с учётом задержки на позиционирование 0.51, получается, что для комфортного просмотра нам нужна минимальная скорость линейного чтения 32/0.51=62.7 мб/сек (отличие в 10% от 57).
Это самый худший случай из возможных, как видно, фрагментация практически не сказывается на производительности при чтении пользовательских данных, при чём файл в данном примере должен быть разбит на 68900 кусков. Если же мы расположим куски файла в пределах 1/10 поверхности диска, то время доступа уменьшится в разы.
А при запуске тяжёлых программ ключевым фактором будет являться количество файлов и разброс их по диску. Для интереса взял IntelliJ Idea, там 1118 jar-файлов общим объёмом 1.25 Гб. Допустим, файлы расположены близко и задержка на позиционирование составит 5 мс, тогда только на позиционирование уйдёт 5.6 сек. Если файлы раскиданы по диску, то увеличим задержку, например, до 15 мс, тогда уйдёт 16.8 сек, а на чтение данных 12.5 сек в обоих случаях (при 100 мб/сек линейного чтения). Суммируем, и получаем 18.1 против 29.3.
Конечно, цифры, по большому счёту, взяты из головы, но суть в том, что не важно, на сколько фрагментов разбит файл, важен размер этих фрагментов и их расположение на поверхности диска. В ФС линукса эти факторы учтены, поэтому фрагментация и не влияет на производительность.
Texnoline
25 июля, 2020 - 17:45
В фс линукса, много параметров учтены, спору нет!:) Кстати хороший расчет позиционирования и задержек, "снимаю шляпу"...
Комментировать