дефрагментация ext3

почитал преимущества ext4 перед ext3 и понял, что ниодно из них мне не нужно.

Хм, даже delayed allocations которые позволят уменьшить фрагментацию (за которую Вы так переживаете) going forward?

В общем, вопрос, есть ли проверенное средство дефрагментации для ext3, которое гарантировано не уничтожит данные?

А Вы оптимист…

ладно, займу на работе диск такого же размера и сделаю дефрагментацию

дефрагментация особенно полезна для ssd

Ради какой великой цели используется ext3, а не ext4? Боязнь цифры 4 или что?

скопировать данные на другой носитель(можно не всё), и скинуть обратно не создавая и не форматируя ничего. 100% дефрагментировать не обязательно

займу на работе диск такого же размера и сделаю дефрагментацию

Может тогда проще отформатировать свой диск и не возиться с файловой системой?

Лучше всего конечно использовать дефрагментатор из Нортон Утилит. Ещё нужен антивирус, Аваст, Комод или Нод32, а так же чистилка реестра.

Если без издевательств — у меня за 25 кажется лет использования Линукс и файловых систем начиная с ext2 и заканчивая ext4, на текущий момент, ни разу не возникала потребность в дефрагментации ФС. Необходимость дефрагментации в винде следствие «особенностей» файловой системы fat32 и NTFS, особенно NTFS, которая адски фрагментируется и тормозит если заполненность диска переваливает за половину. Ext2\3\4 этим не страдает, производительность ФС на практике просаживается очень незначительно. Ну а SSD этот момент на корню убирает.

Если бы вы имели практический опыт эксплуатации — вы бы это знали. Но судя по тому что вы сравнили ext3 с ext4 и выбрали при этом ext3 вы не просто мало знаете, вы ещё и мало что поняли из тех слов что прочли.

Впрочем развлекайтесь как хотите, любым доступным вам способом, это ваш компьютер.

дефрагментация особенно полезна для ssd

А ещё она очень быстро там происходит, можно непрерывно этим заниматься, чтобы SSD не простаивал и работал «на все деньги».

для этого нужно найти фрагментированные файлы

а как вы объясните, что для ext4 есть дефрагментатор, а для ext3 нет, можно сделать косвенный вывод, что ext4 больше фрагментирует файлы

Никак не объясню. Просто кто то захотел дефрагментатор под ext4 и написал его. Почему и зачем он его захотел — я не знаю. Не исключено что просто потому что ему было интересно такой написать, «потому что могу», в качестве практической проверки своих знаний и умений. Но вот об его обильном использовании что то не слышно, равно как и нет настоятельных рекомендаций обязательно его использовать. Возможно это потому что в отличии от Виндоуз и NTFS фрагментация в Linux не имеет таких катастрофических последствий для производительности ФС.

Вы лучше подумайте почему в Виндоуз дефрагментатор встроен в саму ОС и настроен запускаться по расписанию, если диск не SSD, а в Линукс дефрагментатор днём с огнём нужно искать, и в состав комплекта утилит для обслуживания ФС он не входит.

а как вы объясните, что для ext4 есть дефрагментатор, а для ext3 нет, можно сделать косвенный вывод, что ext4 больше фрагментирует файлы

А ещё можно сделать вывод, что Луна сделана из сыра. Связи столько же.

Как там на винде живётся?

Вспомнил детство, раз в неделю этот процесс надо было запускать, часа 3 он занимал)))

Возможно это потому что в отличии от Виндоуз и NTFS фрагментация в Linux не имеет таких катастрофических последствий для производительности ФС.

А вот можно объяснить, почему она их не имеет? Ну да, с SSD понятно, там механики нет. Нот вот применительно к обычному HDD (которые всё ещё актуальны для файлопомоек и долговременного хранения) что такого чудесного творят линуксовые ФС? Физика-то никуда не девается.

Дядь, я ведь не настоящий сварщик, я маску на стройке нашёл. Где то я читал разных вумных статей со страшными словами типа «алгоритмы аллокации», «упаковка хвостов», «физическая локализация и аллокация блоков журнала» и всякие такие ругательства. Вывод был в том что NTFS просто архитектурно говно и без дефрагментатора деградация в ней нарастает в геометрической прогрессии по мере исчерпания свободного места. А в Линукс в разных ФС алгоритмы разные, но в целом более продуманные.

ну, вам такое объяснение не понравится, но если откинуть недочеты NTFS, то можно предположить, что в платной ос должно быть все, от «вантуза», до «прикуривателя», а то что он запускается по расписанию, ну клиент должен знать, что система работает и делает полезные юзеру вещи, не просто так он деньги платил, чтобы компьютер простаивал

еще лифтовый алгоритм Линуса забыли, хотя наверно до Линуса его придумывали раз 100500

Ну, вам такое объяснение не понравится, но в виндоуз изначально не было никакого дефрагментатора. И приобретался этот софт отдельно. Когда вышла NT с NTFS Микрософт тоже торговала своим дефрагментатором, и даже был их «рыночек». Однако специалисты быстро выяснили что собственно код дефрагментатора сразу идет в составе библиотек ОС, а Микрософт и остальные участники «рыночка утилит» торгуют графическими мордами к этому коду. Был скандальчик с потенциалом судебного развития, и Микрософт снизошла до включения «кастрированной» мордочки в состав ОС, продавая при этом её более продвинутую версию в составе дополнительных утилит. Так был убит этот «рыночек», к тому же пользователи обнаружили что «кастрированную» версию таки можно и совсем не сложно заставить таки работать по расписанию (графические настройки запуска «по расписанию» как раз и были кастрированы). После этого Микрософт таки снабдила его «полной» мордой по умолчанию.

Но весь этот ужас происходил тупо из за того что пользоваться Виндой без дефрагментатора становилось решительно невозможно, и это ощущалось «органолептически» после того как диск на две трети заполнялся. А вот в Линукс такого нет, иначе в ней тоже запускался бы дефрагментатор по расписанию.

Я видимо ввязался в какой то идиотский спор. Хотите пользоваться ext3 и дефрагментировать — пользуйтесь и дефрагментируйте. Нет дефрагментатора — напишите. Не можете, но он вам нужен — видимо Линукс не удовлетворяет вашим потребностям, пользуйтесь Виндоус, там дефрагментатор есть.

Вывод был в том что NTFS просто архитектурно говно

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

Вы лучше подумайте почему в Виндоуз дефрагментатор встроен в саму ОС и настроен запускаться по расписанию, если диск не SSD, а в Линукс дефрагментатор днём с огнём нужно искать, и в состав комплекта утилит для обслуживания ФС он не входит.

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

Дядь, я ведь не настоящий сварщик … Где то я читал разных вумных статей

Не, ты только не подумай, что это лично на тебя наезд. Лет 20 назад я, возможно, тоже бы в такой теме на ЛОРе начал говорить «ненужно». Но с тех пор я постарел, стал гораздо большим скептиком и хотел бы получить внятные технические аргументы.

Ну и то, что кто-то написал-таки дефрагментатор для ext4, наводит на подозрения, что не такое уж и «ненужно».

P.S. А вот мнение покойного KRoN73. Да, это 2015 год, но если учесть, что у ТСа вообще ext3…

Лучше всего конечно использовать дефрагментатор из Нортон Утилит.

Хорошая вроде штука, во времена Win98SE.

… Ещё нужен антивирус, Аваст, Комод или Нод32, а так же чистилка реестра.

Чистилка не чистилка, а продвинутый унинсталлер хорошая штука. (Если ее использовать для логирования установки). =)

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

Я так понимаю что важна не сама по себе фрагментация, важно как это на производительности ФС и ОС «в целом» сказывается. А вот на это «в целом» влияют не только дырки между записанными секторами, но и алгоритмы кеширования записи и чтения, алгоритмы работы планировщика IO, грамотная работа с NCQ\TCQ и т.п. Так что фрагментация например есть, а вот деградация производительности может слабо при этом ощущаться. Ну и ещё важно «какая именно» это фрагментация. Что и как фрагментировано и насколько это критично при разных паттернах использования.

Да, мнение покойного не прочёл поскольку ты ссылку на его профиль оставил, а не на сообщение.

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

да, ваше объяснение разрушаем мое, которое и так притянуто за хвост

Ну вот как-то так и получается, что при обычной работе фрагментации в линуксе мало. Но я давно видел систему, на которой просто была одновременная запись примерно в 1000 файлов, файлы росли с нуля до, ЕМНИП, 100 Мб. И чтобы потом эти файлы нормально читались, нужно было либо при создании каждого сразу забивать данными, а потом писать через mmap, либо после записи делать их поштучное копирование в другой каталог, а лучше на другую ФС. Такая «дефрагментация» давала прирост скорости чтения из этих файлов на НЖМД чуть ли не на порядок.

P.S. А вот мнение покойного KRoN73

у вас мнение отклеилось или посмотреть его - надо много звезд

Он ссылку не на мнение, а на профиль дал, ошибся.

да я уже увидел, я подумал сходу, что надо много звезд

Вот видимо так и есть, мне при «обычном» использовании ни разу не хотелось FS дефрагментировать. А вот в Виндоуз потребность в дефрагментации ощущается как физиологическая, на уровне «хочу в сортир терпеть не могу», ну вы все это знаете, загрузка продолжительностью в несколько минут и т.п.

В «специальных» случаях, например при работе с торрентами, обычно на уровне софта применяются методы предотвращения фрагментации, типа предварительного выделения места и т.п. Думаю что в той системе где одновременная запись в 1000 файлов с ростом с 0 до 100 мб тоже можно было бы на уровне софта это вот вытворяющего решение предусмотреть. Но поскольку этого сделано не было ФС с диском были загнаны в условия форсированной фрагментации со всеми вытекающими последствиями. Но ведь это как раз и есть «специальный» случай, а не повседневный сценарий.

В линуксе фрагментация другого характера - пофайловая, или как лно называется.

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

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

С этим боролись с помощью prefetch со стороны ядра, prelink\preload со стороны софта и precached со стороны ОС в целом. Как же хорошо что SSD сделали это всё неактуальным.

Не помню названий. Помню что та шняга, что пропихивалась в Убунту вместо убыстрения замедляла раза в три. Типичное убунтошное...

разве ssd эту проблему не аннулировало?

Насколько я помню, досовский defrag это урезанный norton speed disk. И последующие виндовс версии тоже были лицензированы у Symantec.

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

Ага. Только видимо симантеки и дальше код совершенствовали, потому что я хорошо помню что только их дефрагментатор дефрагментировал MFT на NTFS. А то что было встроено в Виндоус и чем пользовались разнообразные графические морды MFT не трогало и вообще дефрагментировало не так полно как это делала симантековская утилита.

Упс, вот правильная ссылка:

Нужна ли дефрагментация ext4? А дедупликация? (комментарий)

ТС, это и тебе ответ тоже.

Просто скромно добавлю что его мнение относится к нагруженным серверам в постоянной эксплуатации, лично я говорил тут про десктоп. На серверах подход в целом более другой и ответственный. Нагруженных файлохранилищ я не сопровождал, а на ненагруженных использовал либо reiser3, если там свалка мелких файлов, либо JFS для больших (да, не XFS, делал тесты и выбрал JFS почему то, уже не помню почему, может потому что не смог XFS хорошо настроить). Серверы баз данных которые я сопровождал обычно raw разделы использовали под базы.

Ext3\4 на серверах у меня обычно сама ОС пользовала, данные я на ней не хранил. Ну и да, сам сказал, 2015 год, ext4 весьма сильно продвинулась как раз в части аллокации и балансировки, если описания коммитов почитать.

Вынужден признать вашу правоту. Действительно, освежил память и вспомнил что в ext3 нет экстентов, они появились в ext4, и появилась проблема фрагментации которая была не так сильно заметна для ext3. Именно поэтому для ext3 нет утилиты дефрагментации, а для ext4 она есть, и входит в состав утилит, под названием e4defrag.

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

вспомнил что в ext3 нет экстентов, они появились в ext4, и появилась проблема фрагментации

Я не до конца понимаю связь между наличием экстентов и фрагментацией. Можно немножко поподробнее?

https://unix.stackexchange.com/questions/703876/difference-between-fragment-a...

Вот тут есть хорошее объяснение.

Держать систему на харде, а не на ссд самоподписно страдать.

Вот тут есть хорошее объяснение.

Позволю себе не согласится. Там рассказывают что такое фрагменты и экстенты (что более менее и так понятно), но на вопрос «как наличие экстентов влияет на фрагментацию» ответа там нет. Более того - мне трудно себе представить из-за чего такая связь могла бы появится: суть экстентов в более компактном представлении последовательных блоков. И дело даже не в занимаемом месте, а в том что в случае больших файлов прыгать по инодам нужно меньше (прямой профит). Если Вы видите хотя бы одну ситуацию когда фрагментация на ext3 была бы меньше - я бы очень хотел о ней услышать.

Потому что.... ?

Естественно, теперь держать систему на харде мучительно. Кроме того, что производители позасовывали всяких эсэмэров, так ещё и линуксописатели убрали «не те» шедулеры и однопоточный ввод и вывод и вот это вот всё. Но раньше-то мы жили? Для сравнения поставь на хард старый линукс и распоследний, на ядре 6.8999. заметь раздницу

Эмм тут я затрудняюсь «на пальцах» объяснить, я же всё таки «не настоящий сварщик». Экстенты действительно задумывались как средство для уменьшения фрагментации, однако оказалось что есть сценарии при которых в сочетании с механизмом предварительной аллокации фрагментация возрастает, а не уменьшается. Так бывает когда не удаётся предварительно аллоцировать непрерывный кусок, например в ситуации когда в директорию одновременно пишутся и оттуда же удаляются файлы разных размеров. Тут механизм предварительной аллокации в сочетании с экстентами ведёт себя не совсем хорошо. Но именно в этой части проведена большая «работа над ошибками» сейчас.

Если вы ищете аргументы в пользу ext3 против ext4, например сравнивая фрагментацию и её влияние на производительность, вам помогут только тесты на «реальном» железе с интересующим вас паттерном нагрузки. Боюсь что «из теории» тут выводов не сделать. Мне самому было бы интересно результаты посмотреть, ext3 как то подзабыта уже, её уже давно никто не тестировал, тем более с современными ядрами и планировщиками IO, ext4 тоже за этот год получила несколько интересных ускоряющих её коммитов, было бы интересно её потестить в актуальном нынешнем состоянии и сравнить с ext3.

Так что если вы разработаете методику и проведёте тесты с полным описанием методики, указанием опций создания ФС, параметров монтирования и планировщика IO, может получиться весьма интересная, познавательная и актуальная статья.

на ядре 6.8999

Заметил, что шестое ядро на моих одноплатниках и i7 гробе даже грузится на 2-3 секунды дольше, чем 5.15-ое, потому нафиг это шестое.

Экстенты действительно задумывались как средство для уменьшения фрагментации

Это ложное утверждение. Экстенты используются исключительно для упрощения адресации блоков. Вместо одинарной, двойной и, вроде, тройной косвенной адресации, где в итоге перечисляются каждый из использованных блоков, экстенты позволяют сократить метаинформацию, сохраняя только информацию о непрерывных отрезках блоков. К способу размещения блоков в свободном пространстве это не имеет никакого отношения. С натяжкой к теме фрагментации можно притянуть худший случай экстентов, когда все отрезки имеют длину в один блок. В таком худшем случае информация об экстентах займёт как минимум в два раза больше места, чем перечисление блоков, как в ext2. В этом случае метаинформация съест немного больше места, оставив меньше свободного места для файлов, что потенциально может привести к большей фрагментации.

Возможно, путаница возникает из-за того, что в ext4 одновременно были добавлены и экстенты и отложенное размещение. Вот отложенное размещение это оптимизация для увеличения скорости доступа и снижения фрагментации. У драйвера ФС есть несколько секунд, чтобы собрать достаточно данных и выделить достаточный запас места. Выделение с запасом было ещё в ext3, но в ext4 у драйвера больше информации для принятия решений. Если файл короткоживущий, ext4 может вообще не писать его содержимое на накопитель.

ext4 тоже за этот год получила несколько интересных ускоряющих её коммитов, было бы интересно её потестить в актуальном нынешнем состоянии и сравнить с ext3.

Тут будет сюрприз. Уже несколько лет как в ядре отсутствует драйвер для ext3. Вместо него используется драйвер ext4, который может монтировать и ext4, и ext3, и ext2.

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

У корневой ФС (35 гигов) около пяти с половиной лет. На ней стоит Debian testing, который я раз в пару недель обновляю. Файл /usr/lib/chromium/chromium, который живёт на корневой ФС, разбит на 374 кусочка, разбросанные чуть ли не по всей корневой ФС. Начинается с 92 кусочков в районе 21-го гига, потом 68 кусочков в 28-м, затем 13 кусочков в втором гигабайте, 6 в 32-м, 30 в 18-м, 29 в 4-м, 62 в 10-м, 27 в 30-м, 34 в 27-м, 13 в 28-м и ещё один в первом. То есть файл мало того что разбит, так ещё и не размещён в порядке увеличения номеров блоков.

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

У меня gentoo, обновляю я её заметно реже, чем раз в две недели и за три года хромой состоит из 26 экстетнтов (по данным filefrag), а всего в системе:

  826716 inodes used (19.83%, out of 4169728)
    4619 non-contiguous files (0.6%)
     322 non-contiguous directories (0.0%)

Не знаю, почему у вас так, либо ФС была в какой-то момент сильно забита, либо в дебиане обновление параллельно разворачивает файлы. Так ведь, сначала скачивается пакет, фактически архив, и из него по одному устанавливаются файлы. То есть запись в один поток, с этим ext4 должна нормально справляться.

Чтобы на SSD стала заметна фрагментация

Это для рядового пользователя, которому что 0,1 секунда, что 1,0 секунда особо без разницы. А как только система должна перелопачивать большие объёмы данных, хочется, чтобы скорость чтения из файла была соспоставима с линейной скоростью чтения накопителя. Не знаю почему, но рандомное однопоточное чтение с ssd на порядок медленее последовательного, хотя физически данные обычно раскиданы по разным островам.