Нискы и фрагментация
Вот мне интересно - линуксятники намереннно закрывают глаза на существование такой проблемы, как фрагментация ФС, или их ФС устроена каким-то таким волшебным способом, что фрагментации на ней не бывает? (Расскажите мне, какая идея хранит ext3 от фрагментации, и я сделаю вам вечный двигатель!)Обычно не бывает. При особенных паттернах использования бывает.
после очередного крупного апдейта ОС у него всё стало безбожно тормозить?Так не бывает. Аллокатор ФС заточен как раз под подобные паттерны.

Так не бывает. Аллокатор ФС заточен как раз под подобные паттерны.То есть, у ext3 такой проблемы в принципе нет, а во всём виновата МС, насаждающая свой кошмарно фрагментирующийся ntfs?
Обычно не бывает. При особенных паттернах использования бывает.У меня доволбьно мало свободного места на винте.
Я скачал .tgz нового ядра, сконфигурил, собрал, поставил (взамен старого ядра); скачал .tgz опенофиса, сконфигурил, собрал, поставил; ещё раз обновил ядро (из исходников); снёс ОО... и ФС осталась свежей и чистой?
Вопрос даже не в том, насколько линуксовые фс этому подвержены, а в том, что в поставку ОС, про которую все говорят "вот как тут всё заебись, в дистрибутиве 10 редакторов текста, десять шеллов, десять браузеров и десять плееров, а в вашей винде только один браузер, да и тот без жестов мыши" не входит ни одна утилита для дефрагментации.
В принципе есть, на практике нет.
Это если вместо еженедельной дефрагментации соблюдать правила по разбиению диска и использованию разделов.
> У меня доволбьно мало свободного места на винте.
> скачал .tgz опенофиса, сконфигурил, собрал, поставил; ещё раз обновил ядро (из исходников)
Если ты всё это проделываешь, места достаточно.

но тормозов от неё нет, это же не вендаАга, и трения в линуксах тоже нет, как и силы тяжести - это же не винда

В принципе есть, на практике нет.То есть, говорится "у обычного пользователя такого не будет, а у тех, у кого будет - сами виноваты".
Это если вместо еженедельной дефрагментации соблюдать правила по разбиению диска и использованию разделов.У меня 160гб винчестер с фильмами (практически все файлы на нём ~1гб через год после покупки (вс время качались новые фильмы, стирались старые) он стал уж совсем безбожно тормозить; попробовал дефрагментировать - там практически все файлы были побиты на десятки фрагментов.
Это винда такая плохая, или что? Если бы я то же самое делал в линуксе под ext3 - всё было бы заебись?
У меня линукс в вмвари. Я хз, как он там ставился, но так получилось, что выжрала мандрива 3гб дисковой памяти во врем установки; сейчас на единственном разделе что-то около полутора гигов данных.
Что мне сделать, чтобы вернуть реальной машине те 1.5 гига, которые сейчас пропадают в никуда? В вмвари написано "сначала дефрагментируйте разделы в виртуальной машине, затем нажмите на кнопку "дефрагментировать" в самой вмвари"; но дефрагментировать разделы в виртуальной машине я не могу, потому что линукс, а без этого дефрагментация в самой вмваре высвободила мне только несколько десятков метров.
попробовал дефрагментировать - там практически все файлы были побиты на десятки фрагментов.фильм - это больше 500М
десятки фрагментов - это не более 100
значит, не менее 5М на фрагмент в среднем
такая фрагментация не отразится заметным образом на работу с фильмом
если "безбожно тормозило" - видимо, были другие причины
Не понял, как такое возможно. Тормоза от фрагментации не зависят от оси, а от винчестера. Если с забитого диска удалить рандомную пачку мелких файлов, а потом залить туда фильм, то фрагментация должна появиться обязательно. Не представляю, как это можно обойти на уровне ФС. Лениво читать мануал, поясните идею. Относительно каких еще ФС это верно?
Раньше, когда винты были меньше, и реально было добиться такого же, но без фильмов и прочей мультимедии, утилита для дефрагментации ext2 была.
Тормоза от фрагментации не зависят от оси, а от винчестера
Не представляю, как это можно обойти на уровне ФСВот и я про это.
Но линукс, видимо, использует какую-то высоколевельную магию, которую нам, простым смертным, не понят. Скоро компьютеры с линуксом, наверное, смогут работать вечно и без розетки, и будут работать в интернете на 1гбпс даже в тайге

такая фрагментация не отразится заметным образом на работу с фильмомУ меня отражалась.
если "безбожно тормозило" - видимо, были другие причиныА почему после дефрагментации всё залетало?
Фильмы медленно смотрелись?
> А почему после дефрагментации всё залетало?
Возможно, ты плохо описал проблему. А может, твоя ФС сильно тормозит на доступе к фрагментам.
Идея в том, что незачем держать на полностью забитом разделе (1) одновременно пачку мелких файлов (2) и фильмы (3).Полностью забитый раздел - не такая уж и редкость, место всегда кончается.
То есть, линуксятники просто делают два разных раздела для данных (один для фильмов, другой для мелких данных - причём, труъ-линуксоиды всегда знают, сколько гигов им выделить под фильмы, а сколько - под мелкие данные и ничего не удаляют с системного раздела (да, ещё - у них этот самый системный раздел бесконечно большой)?
Я бы тебе сказал сейчас, насколько сильно у меня фрагментируется системный раздел, но, вполне возможно, что это действительно os-dependent (типа "а у вас программы не такого размера, как у нас" поэтому и написал про винчестер с фильмами (там ситуация не настолько страшная, но тоже показательная).
Фильмы медленно смотрелись?Ага, периодические замораживания кадров, хруст винта итп.
ЗЫ: А если данные переливать очень интенсивно (например, содержимое раздела полностью обновляется через 1 час)? Предлагаешь каждую ночь очищать раздел целиком?
ЗЗЫ: Да, езё, совсем забыл - мы ведь не только смотрим фильмы и ставим софт, у нас ведь ещё и логи есть (к которым постоянно что-то дописывается). Как такие логи смотреть/копировать, и что будет, когда у меня начнёт кончаться место, я не смогу поставить свой любимыйы опенофис, и удалю логи?
любая ФС подвержена фрагментации, но в современных ФС используются разнообразные эвристические алгоритмы минимизирующие фрагментацию ФС.
я использую ReiserFS под Gentoo. Все программное обеспечение компилируется из исходников сам понимаешь какая это нагрузка на ФС. Этот раздел существует в таком режиме уже не первый год и пока видимых невооруженным взглядом проблем нету.
PS вообще проблема хорошо освещена в англоязычной википедии.
Если ты удалишь с такого сразу много мусора, а не ровно столько, чтоб высвободить место под один фильм, то всё нормально будет.
> и ничего не удаляют с системного раздела (да, ещё - у них этот самый
> системный раздел бесконечно большой)?
На системном разделе файлы в основном маленькие, и от фрагментации заметно не страдают.
А раздел, как правило, действительно бесконечно большой, потому что там надо всего несколько гигов, а винты сейчас в сотни гигов.
> периодические замораживания кадров
Походу, твоя ФС - просто говно, отсюда и проблемы.
На боевом сервере /var должен быть отдельным разделом.
Может быть, даже /var/log.
> что будет, когда у меня начнёт кончаться место
В зависимости от того, как настроишь.
---
"Аллах не ведёт людей неверных."
Короче, красноглазый друг, ты начал тред - ты получил ответ. Зачем продолжаешь дискуссию, когда ответ повторен уже несколько раз? Тебе домашнее задание: сильно фрагментировать раздел под ufs или ext2fs. Когда у тебя это получится, то продолжим дискуссию.
В вмвари написано "сначала дефрагментируйте разделы в виртуальной машине, затем нажмите на кнопку "дефрагментировать" в самой вмвари"Как дефрагментация связана с освобождением места - это нужно спрашивать у разработчиков вмвари - у нас тут никто не курит такую траву. Видимо, этот совет работает только для виндов.
Я бы рекомендовал создать новый раздел, скопировать всё туда, а старый удалить - точно всё высвободится.
Если ты удалишь с такого сразу много мусора, а не ровно столько, чтоб высвободить место под один фильмТо есть, если у меня кончается место на винте с фильмами, а я имел глупость когда-то перейти на линукс - мне надо очистить сразу половину винта?
Тебе домашнее задание: сильно фрагментировать раздел под ufs или ext2fs. Когда у тебя это получится, то продолжим дискуссию.К сожалению, явно мне это показать не получится - потому что линуксятники, как оказалось, настолько яростно отрицают существование проблемы фрагментации, что даже не подумали включить какую-нибудь утилиту для анализа раздела. А то я бы тебе показал статистику по разделу с мандривой.
Экспериментировать с большими разделами и фильмами сейчас, к сожалению, не могу, потому что всё дисковое пространство, которым я сейчас владею, за исключением, может быть, гигов 5, мне нужно.
Тем не менее, как же всё-таки оказалось, что раздел со свежеустановленной мандривой, на котором сейчас 1.5 гига данных, не ужимается сильнее, чем до 3-с-чем-то гигов?
Я бы рекомендовал создать новый раздел, скопировать всё туда, а старый удалить - точно всё высвободится.А, то есть у линуксятников всё так?
"Начинает тормозить винт - создай новый раздел и перенеси всё на него, а старый удали", "начинает глючить система - переустанои", "начинает глючить комп - купи новый"?
Как дефрагментация связана с освобождением места - это нужно спрашивать у разработчиков вмвари - у нас тут никто не курит такую травуВМварь тут ни при чём, такой же странный эффект, представь себе, наблюдается ещё и у всяких там partitionmagic-ов. не могут почему-то уменьшить раздел, по которому случайно раскиданы куски данных от начала до конца раздела; зато если все данные собраны в первой половине раздела, эти программы каким-то образом ухитряются откусить от этого раздела вторую половину. Представляешь?
На боевом сервереА на домашней машине в /var/log ничего не пишется?
Ты живёшь прямо в каком-то придуманном мире.
ещё и у всяких там partitionmagic-ов. не могут почему-то уменьшить раздел, по которому случайно раскиданы куски данных от начала до конца раздела; зато если все данные собраны в первой половине раздела, эти программы каким-то образом ухитряются откусить от этого раздела вторую половину.resize2fs, resize_reiserfs - умеют так собирать данные
> А на домашней машине в /var/log ничего не пишется?
> Ты живёшь прямо в каком-то придуманном мире.
На домашней машине пишется настолько мало, что этим
можно пренебречь.
---
"Мы диалектику учили не по Гегелю."
"Начинает тормозить винт - создай новый раздел и перенеси всё на него, а старый удали", "начинает глючить система - переустанои", "начинает глючить комп - купи новый"?На домашнем компе не переставлял систему с момента установки - 6 или 7 лет. Фильмы смотрятся нормально. Новый комп тоже не покупал - апгрейдил по частям.
К сожалению, явно мне это показать не получится - потому что линуксятники, как оказалось, настолько яростно отрицают существование проблемы фрагментации, что даже не подумали включить какую-нибудь утилиту для анализа раздела.Просто ты не можешь её найти.
Кстати, если знаешь, подскажи для FFS.
Мне аж самому интересно стало.
---
...Я работаю...
Например fsck_ffs в конце работы выводит. А вообще если поискать по интернету, то чего только не найдёшь для open source fs. Эта оценка фрагментации чуть ли не любимая тема для дипломных работ.
Просто ты не можешь её найти.Подскажи, плз, где искать? Мандрива 2005, ext3. Поиск файла с frag в имени не помог, поиск пакета, содержащего в названии/описании/именах устанавливаемых файлов frag - тоже.
ЗЫ: filefrag, естественно не подходит.
Я не знаком с Мандрива 2005. И вообще конкретно тебе подсказывать не хочется. Всякая новая информация для тебя является новой пищей для новых идиотских постов.
через год после покупки (вс время качались новые фильмы, стирались старые) он стал уж совсем безбожно тормозитьа может у тебя диск был на нтфс забит более чем на 90% и ты перед дифрагментацией освободил немного места? Вроде бы ntfs не любит, когда свободного места на диске становится менее 10%, начинает всякой ересью заниматься...
Вроде бы ntfs не любит, когда свободного места на диске становится менее 10%, начинает всякой ересью заниматься...Это как?
Если у меня остаётся только 10% свободного места - драйвер нтфс начинает по ночам перемешивать куски файлов?
Диск NTFS поделен на две зоны. В начала диска идет MFT зона - зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается ровно в два раза. И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% - фрагментация растет как бешенная.
http://www.ixbt.com/storage/ntfs.html
В результате если NTFS работает при диске, заполненном на около 90% - фрагментация растет как бешенная.Тем не менее, если _активно_ работать с большими файлами - всё будет достаточно прилично (когда занято 99%, удаляется несколько больших файлов, которые дадут достаточно много непрерывного места).
А вот от проблемы фрагментации в целом никуда не деться, даже в линуксе.
Допустим даже, что нету никакой mft - забил я винт фильмами на 99%, хочу записать новый фильм (весит 700 метров) - места нет; удаляю старый фильм (699м записываю новый - вот уже фрагментация файлов

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

Не надо никуда меня перенаправлять.
глупое пожелание, я бы точно не стал терять время, отписываясь что да почему
СЛАВА ЛИНУКСУ!

bugaga ~ $ emerge -s defrag
Searching...
[ Results for search key : defrag ]
[ Applications found : 1 ]
* games-fps/quake3-defrag
Latest version available: 1.91.08-r1
Latest version installed: [ Not Installed ]
Size of files: 86,695 kB
Homepage: http://www.planetquake.com/defrag/
Description: Quake III Defrag - Trickjumping challenges for Quake III
License: freedist
И все-таки, почему ext3 устойчива к фрагментации?Мне не кажется, что она устойчива к фрагментации. Создал у себя два опытных ext3 раздела по 256 Мб каждый. Забил под завязку файлами примерно по мегабайту, так чтобы было по 256 файлов. В одном случае плясал-танцевал с маленькими файликами, их удалениями и прочей фигней. В другом случае создавал их просто друг-за-другом. В итоге результаты примерно таковы:
dsme tmp # fsck -fn /tmp/ext3-frag
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/tmp/ext3-frag: 267/65536 files (96.6% non-contiguous 262144/262144 blocks
dsme tmp # fsck -fn /tmp/ext3-defrag
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/tmp/ext3-defrag: 267/65536 files (21.0% non-contiguous 261512/262144 blocks
dsme tmp # mount -o loop /tmp/ext3-frag /tmp/test-frag
dsme tmp # mount -o loop /tmp/ext3-defrag /tmp/test-defrag
dsme tmp # dd if=/tmp/test-frag/big-0 of=/dev/null bs=4096
235+0 записей считано
235+0 записей написано
скопировано 962560 байт (963 kB 2.00473 c, 480 kB/c
dsme tmp # dd if=/tmp/test-defrag/big-0 of=/dev/null bs=4096
236+0 записей считано
236+0 записей написано
скопировано 966656 байт (967 kB 0.103036 c, 9.4 MB/c
Скорость чтения файла на фрагментированном разделе упала на порядок

1. Дефрагментация файлов, которые представляют собой расширение оперативной памяти. Так называемые файлы подкачки. Такие файлы критичны по скорости доступа. Поскольку от этой скорости зависит производительность системы вцелом. В Linux эта область располагается на отдельном разделе, что полностью исключает фрагментацию.
2. Дефрагментация файлов, хранящих критически важную информацию, постоянно используемую системой. Например файл с реестром Windows. В Linux нет реестра и похожих данных. В Linux используются индексные файлы везде, где необходимо производить поиск по файловым каталогам. И используются они только в момент действительной необходимости.
3. Дефрагментация файловой системы в целом для улучшения производительности. На самом деле эта цель дает прирост лишь на медленных носителях малого объема, таких как жесткие диски со скоростью 5400. При таких условиях максимум что может дать дефрагментация: несколько десятков свободных кластеров и прирост к скорости не больше 0,5% (tomshardware.com) . В других случаях дефрагментация является бессмысленной. Если учесть, что в Linux - е файлы операционной системы и системного софта лежат в отдельном логическом разделе от личных файлов пользователей, то влияние пользовательской файловой активности на фрагментацию системного раздела практически равно нулю.
Доступ к файлам в Линуксе ускорен кэшированием дисков. Если нет активности пользователя и свободной оперативной памяти много, то линукс втихаря начинает закидывать наиболее используемые файлы в память, образуя кэш из очень быстрых файлов
взято отсюда http://www.fforum.ru/index.php?s=46963bcf3ccb7d813c148ca1790...
тут еще есть про фрагментацию и дефрагментаторы для линукса
http://www.insidepro.com/kk/126/126r.shtml
про вмварь и образ
вот тут есть лишняя галочка, которая не позволит освободить место

что такое allocate знаем?
tomshardware.comАга, нашёл достоверный источник.
Доступ к файлам в Линуксе ускорен кэшированием дисков. Если нет активности пользователя и свободной оперативной памяти много, то линукс втихаря начинает закидывать наиболее используемые файлы в память, образуя кэш из очень быстрых файловВ винде тоже, и что?
В Linux используются индексные файлы везде, где необходимо производить поиск по файловым каталогамА эти индексные файлы, надо полагать, никогда не фрагментируются?
что такое allocate знаем?Знаем-знаем.
И куда там, по-твоему, надо было её применить?
А эти индексные файлы, надо полагать, никогда не фрагментируются?вот именно, для него практически нет фрагментации, а вот тормоза на нтфс как раз вызваны фрагментацией журнала и индексов на системных разделах, пщоэтому тру чуваки никогда не ставят program files на системный диск в венде. Сколько себя помню, дефрагментатор запускал раза два наверно и то когда диск начинал издавать мучительные звуки от елозенья головок, в линуксе пока такого ни разу не наблюдал, хотя может это правильно настроенный hdparm
Знаем-знаем.
И куда там, по-твоему, надо было её применить?
в том то и дело, что если ты поставил эту галку, то место зарезервируется, и образ как ни крути будет весить 3 гига и фрагментация здесь совершенно ни при чем
если ты поставил эту галку, то место зарезервируется, и образ как ни крути будет весить 3 гигаЭто всё понятно.
Но я-то хочу, чтобы он весил не три гига, а полтора!
А если при создании виртуальной машины сказать, что объём винта - 1.5гб, мандрива не поставится из-за нехватки места.
вот именно, для него практически нет фрагментацииЭто магия?
пщоэтому тру чуваки никогда не ставят program files на системный диск в вендеТо есть, /usr тоже надо делать отдельным разделом? А как распределить место? И что делать с фрагментацией системного раздела после обновления ядра и фрагментацией /usr после установки/снесения пары программ?
Сколько себя помню, дефрагментатор запускал раза два наверно и то когда диск начинал издавать мучительные звуки от елозенья головок, в линуксе пока такого ни разу не наблюдал, хотя может это правильно настроенный hdparmДа, видимо, hdparm.
Потому что у меня в линуксе елозенье головок есть с самого начала.
Но я-то хочу, чтобы он весил не три гига, а полтора!не ставь эту галку! у меня точно такой проблемы никогда не возникало. Размер образа, занимаемый полутарогиговым линуксом был незначительно больше, мегов на сто - двести, возможно из-за того, что вмварь вроде как делает своп
А если при создании виртуальной машины сказать, что объём винта - 1.5гб, мандрива не поставится из-за нехватки места.
Это магия?
нет, не магия, почитай спецификации ext3, не знаю как для других файловых систем
То есть, /usr тоже надо делать отдельным разделом? А как распределить место? И что делать с фрагментацией системного раздела после обновления ядра и фрагментацией /usr после установки/снесения пары программ?
во-первых, ядро лежит не в /usr
во вторых, даже на самых фрагментирумых ФС на относительно небольшом разделе фрагментация на скорость влияет назначительно, да и для маленьких файлов почти ее нет
для убедительности привожу пример своего разбиения диска (оно далеко не самое оптимальное, /tmp на другом конце диска от / , /var и /usr это глупость, да и размеры не самые оптимальные)

...Но его можно туда запихнуть.
---
...Я работаю антинаучным аферистом...
не ставь эту галку!Ну так я и не ставил!
А проблема, видимо, получилась из-за того, что установщик напихал на единственный раздел полтора гига каких-то временных установочных файлов, затем собственно поставил систему (ещё полтора гига) и временные фапйлы удалил. Занято на разделе 1.5гб, а вмварь думает, что все 3.
во-первых, ядро лежит не в /usrА я говорил, что в /usr?
Я спросил, что будет с _основным_ разделом после пересборки ядра, или с /usr после установки/удаления программ.
И все-таки, почему ext3 устойчива к фрагментации? Принцип, механизм (как угодно назовите) объясните.Ничего сверхъестественного.
1. Области для битмапов выделяются заранее, соответственно не могут фрагментироваться в последствии (как MFT).
2. Разделение на группы цилиндров помогает уменьшить фрагментацию, если ФС не слишком заполнена.
3. Небольшая преаллокация для открытых файлов.
4. Некоторые эвристики в аллокаторе (например, Orlov allocator).
Могу сказать, что в том случае, когда я реально наблюдал жуткую фрагментацию, дефрагментатор бы не помог, так как выполнялся бы точно не быстрее, чем работа с фрагментированными файлами (которая так же была периодической). Сервис был круглосуточный, удобного времени для дефрагментации просто не было. Решение - разнести файлы с разными паттернами доступа по разделам.
Я заметил, какая у меня (была) фрагментация на одной из
перезагрузок после нештатного выключения питания:
/usr --- 0,4%, /var --- 0,1%, /home не заметил (поздно было
но тоже какой-то мизер. Все три раздела --- FFS, /usr был забит
под завязку тремя версиями /usr/src и /usr/obj после двух часов
экспериментирования с ядрами.
---
...Я работаю антинаучным аферистом...
Могу сказать, что в том случае, когда я реально наблюдал жуткую фрагментацию, дефрагментатор бы не помог, так как выполнялся бы точно не быстрее, чем работа с фрагментированными файлами (которая так же была периодической). Сервис был круглосуточный, удобного времени для дефрагментации просто не было. Решение - разнести файлы с разными паттернами доступа по разделам.+1
чё за проценты?
Если хочешь высвободить свои 1.5Гб и считаешь, что дефрагментация поможет, то используй программу e2defrag. Она работает на ext2, так что если у тебя ext3, сначала убей журнал раздела (tune2fs, работает на отмонтированном разделе)
у меня есть более важные задачи, чем изучение fsck_ffs(8).
---
...Я работаю антинаучным аферистом...
Оставить комментарий
kruzer25
Я тут слышал много всяких речей в стиле "винда говно, в ней вот такая вот проблема, которую решать надо с бубном, а линукс - это заебись, у него даже проблемы такой нет".Вот мне интересно - линуксятники намереннно закрывают глаза на существование такой проблемы, как фрагментация ФС, или их ФС устроена каким-то таким волшебным способом, что фрагментации на ней не бывает? (Расскажите мне, какая идея хранит ext3 от фрагментации, и я сделаю вам вечный двигатель!)
Я, конечно, понимаю, что мне в вмвари, куда я линукс ставлю с целью "посмотрел-снёс" это неактуально, но что делать среднестатистическому васе пупкину, который заметил, что после очередного крупного апдейта ОС у него всё стало безбожно тормозить?
Перерыл все дистрибутивы убунты 5.04 и мандривы 2005, облазил вс, что только нашёл, в программах из категории "система" - но ничего для дефрагментации не нашёл. Может, не там смотрел, может, надо было ввести mkfs чего-то-там? CtrlAltDel, засунуть диск с виндой и поставить её?