Не раз и не два я пытался выяснить для себя этот вопрос - всё сводится к тому, что файловые системы в *nix-системах не подтвержены ей настолько, как FAT и NTFS. Но в вопросе надо разобраться - и поэтому приглашаются комментаторы.
Для меня этот вопрос представляет академический интерес: то есть "нет, ну а почему!?". Ответ(ы) на него кто-то знает, ибо исходные коды файловых систем и представляет себе всю кухню. Отвечают обычно так:>почему "ненужна" в линухе?
/>Что отвечать?
что из-за большей продуманности:
0) фрагментация очень мала
1) она не приводит к ТАКИМ тормозам системы как в виндах
поэтому, фрагментацией и её последствиями можно пренебречь, а, следовательно, дефрагментация не требуется.
И всё-таки, почему?
На основе полезных ссылок и ценных комментариев на праздниках напишу пост. Давайте вместе разберёмся.
P.S. Для особо ироничных анонимных аналитиков: гугление и яндексование к положительному результату не привели, вопрос поднимался не единожды, но на моей памяти к какому-то вразумительному выводу никто не пришёл. Ещё раз: давайте вместе разберёмся.
Дефрагментация файловых систем в Linux - нужна или нет?
Подписаться на:
Комментарии к сообщению (Atom)
43 комментариев: |высказаться!| RSS-лента дискуссии.|
> что из-за большей продуманности:
> 0) фрагментация очень мала
> 1) она не приводит к ТАКИМ тормозам системы как в виндах
0) Большей продуманности в каком моменте? (NTFS также использует методики уменьшения фрагментированности, если верить M$. В этом можно удостовериться видимо только по косвенным признакам.)
1) Какой адекватный критерий фрагментации (и, как следствие, оценки падения быстродействия). То есть как получить комплексную оценку количества фрагментированных файлов, количества фрагментов каждого файла, физическое расположение (расстояние) фрагментов одного файла, минимальный размер фрагмента, особенности работы жёсткого диска (скорость поиска фрагментов расположенных на одной физической дорожке высока, в случае stripe массива все фрагменты могут быть расположены поочерёдно на разных физических дисках и т.п.)?
2) "ТАКИЕ тормоза" -- это, собственно, какие (следствие ли это фрагментации)?
3) Учесть факторы эксплуатации файловой системы: среднесуточную статистику создания/удаления/изменения файлов, интенсивность обращения к фрагментированным файлам, прирост/убыль свободного пространства и его фрагментированность. Учесть особенности работы алгоритмов оптимизирующих размещение фрагментов в близкорасположенных физических блоках в условиях малого количества свободного пространства.
Кстати, встречал интересное мнение, что фрагментированность файловой системы под windows не так страшна, как кажется.
Аргументы были такие - поскольку происходит частое обращение к разным файлам, то когда они фрагментированы и "размазаны" по дискуЮ головке приходится меньше метаться.
Честно говоря, ничего не могу сказать ни в пользу этого утверждения, ни в его опровержение, но жизненное наблюдение сводится к следующему: "когда коту нечем заняться, он вылизывает яйца. Когда нечем заняться пользователю windows, он дефрагментирует диск" :)
P.S. Может отключить капчу? Спам вроде и так неплохо отсекается.
Единственный разумный довод в пользу дефрагментации который я слышал был "Меньше летает головка по диску".
С точки зрения многопользовательских (и многозадачных) систем это все имеет мало смысла. Голова все равно будет метаться. Причем крайне слабо предсказуемо.
Также есть сильное подозрение что при нормальном (в математическом смысле слова) распределении фрагментов по диску, среднее время доступа будет меньше чем при дефрагментированном варианте. Такой вот казус.
>Кстати, встречал интересное мнение, что >фрагментированность файловой системы под >windows не так страшна, как кажется.
вот только по своему опыту могу скзаать, что после использования полугода/года винды 2000 без всяких переустановок и дефрагментаций, после прохода ndd бегать она начинала шустрее..
Было это правда 6 лет назад, как сейчаст там не в курсе :)
Недавно проверял фрагментацию /home раздела каким-то скриптом. Показал 10% файлов фрагментиованно, не знаю, много это или мало :)
Ссылка на научный проект по поводу фрагментации в ReiserFS.
http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/
Юниксовые ФС действительно заметно меньше фрагментируют файлы. Читал, например, про XFS - там идея состоит в том, что данные на диск не пишутся до тех пор, пока хватает памяти. Соответственно есть возможность перегруппироовать данные при записи, чтобы не было фрагментации. Ну и должно быть понятно, почему вообще нет средства дефрагментации для XFS - она расчитана на разделы по много терабайт, представляете сколько такой раздел будет дефрагментироваться? Так что эта ФС создавалась с расчетом, чтобы фрагментации вообще не возникло.
2Portnov
XFS не подходит для домашних линуксов. Очень высока вероятность потерь данных при потере питания.
Большинство всё-таки ext3 использует...
Афтор жжот, каменты жгут :)
Для линукса всё зависит от выбранной FS, общепринятая ext3 без тюнинга для стандартных задач не требует внимания. Для нестандартных - надо оттюнить один раз и всё.
Насчёт всяких там ReiserFS, XFS, и прочих точно не знаю, но знаю шо они не хуже ext2, а то и лучше ext3.
UFS2 из FreeBSD тоже не требует внимания.
Вообще фрагментация для этих FS - нормальное явление и никогда не превышает 1%-2%. Более того, фраментированные файлы не снижают производительность настолько, насколько это можно заметить.
Опять же, все эти ФС используют тэйлпекинг, он же block suballocation, и ничего, никто не жалуется на уменьшение производительности :)
Опять же позиционирование головок всегда учитывается при форматировании и размещении структур этих FS.
Короче, фрагментация в Винде, и фрагментация в нормальных FS - вещи совершенно разные. Фрагментация в NTFS тоже была бы не страшна, если бы не вышестоящие функции ядра винды, которые не умеют оптимально пользоватся собственной же ФС.
И вообще, читайте доки, они рулят :)
http://en.wikipedia.org/wiki/Unix_File_System
http://en.wikipedia.org/wiki/Ext3#Defragmentation
http://en.wikipedia.org/wiki/NTFS#Internals
http://en.wikipedia.org/wiki/Comparison_of_file_systems
http://en.wikipedia.org/wiki/File_system_fragmentation
> XFS не подходит для домашних линуксов. >Очень высока вероятность потерь данных >при потере питания.
ну не скажи, у меня за полтора года ее эксплуатации ни разу с ней проблем не было, в оличии от рейзера.
Зря вы так про гуглщиков. Кое-то и можно найти: http://www.crossplatform.ru/?q=node/322.
Основная идея нефрагментируемости ext3 - предварительное размещение блоков для файлов перед их использованием. Тогда получается, что при увеличении файла он не подтвергается фрагментированию.
XFS - она расчитана на разделы по много терабайт, представляете сколько такой раздел будет дефрагментироваться? Так что эта ФС создавалась с расчетом, чтобы фрагментации вообще не возникло.
В корне неправильно, XFS фрагментируются так же как и любая другая фс. Более того имеет штатные средства онлайн дефрагметации.
http://amgyk.blogspot.com/2008/05/xfs.html
drujebober, а какие у вас проблемы с райзером возникли?
Интересно, я как раз собираюсь сервер на Дебиане делать, хочу поставить именно райзер.
Конечно фрагментация есть, её не может не быть. Иначе как получается - это должен быть какой-либо интеллектуальный драйвер фс, который распределяет информацию, фактически выполняет дефрагментацию "на лету", но мне кажется это сильно скажется на производительности фс, особенно в случае когда много маленьких файлов.
Самая надежная и простая дефрагментация - перемещаем все файлы на другой, чистый раздел (т.к. обработка идет по файлам а не по секторам) - файлы уже не будут фрагментированы, останется переместить их обратно. Я лично так и делал пару раз.
Митя,
та вобщем то проблемы все решаемые, и возникали при сбои в питании, когда упс отсутствовал, а так никаких претензий, имхо - для сервера оптимальный вариант.
Я думаю, что файловые системы linux (ext-2,3, raser, xfs) при сильной фрагментированности, если возникнет, не настолько теряет производительность, насколько заполненный NTFS раздел. Как следствие полагаю, что дефрагментация не нужна.
http://ols.108.redhat.com/2007/Reprints/sato-Reprint.pdf
Это доклад об онлайн дефрагметации ext4 на Linux Symposium 2007. В начале есть тесты того, как фрагментация влияет на производительность.
Так, народ, прошу отписываться по существу и со ссылками. Обсуждение файловых систем не предполагается - только их фрагментация. Надо этот вопрос уже как-то решить в конце концов.
2 StraNNicK пишет...
P.S. Может отключить капчу? Спам вроде и так неплохо отсекается.
Отключил на время.
2 madw пишет...
после использования полугода/года винды 2000 без всяких переустановок и дефрагментаций, после прохода ndd бегать она начинала шустрее..
С этим чудищем всё понятно - на ixbt была статья о том, как через одно место была сделана NTFS и её дефрагментация. Интересуют никсовые FS.
2 Анонимный пишет...
Ссылка на научный проект по поводу фрагментации в ReiserFS.
Огромное спасибо!
2 Portnov пишет...
Читал, например, про XFS - там идея состоит в том, что данные на диск не пишутся до тех пор, пока хватает памяти. Соответственно есть возможность перегруппироовать данные при записи, чтобы не было фрагментации.
Здорово. Если вспомнишь ссылку - кинь, если не трудно.
2 jankkhvej пишет...
Афтор жжот, каменты жгут :)
Афтора задолбали дятлы с вопросами о фрагментации, а так же такие вот умники со словами "читайте маны". Где хоть одна НОРМАЛЬНАЯ статья про то, как фрагментируются FS в никсах!?
общепринятая ext3 без тюнинга для стандартных задач не требует внимания.
Это слова, а мне нужны ссылки.
Для нестандартных - надо оттюнить один раз и всё.
Ну так поведай нам, сенсей, как это сделать!
Опять же позиционирование головок всегда учитывается при форматировании и размещении структур этих FS.
Я спросил авторитетного мнения насчёт фрагментации. Как\чем мерить и как\надо ли бороться и ПОЧЕМУ. Вопли "никсовые фс Ъ" я могу и на ЛОРе накопать тоннами.
И вообще, читайте доки, они рулят :)
А я их думаешь не читал!? Там те же самые ля-ля про современные никсовые ФС и ни слова о том, почему это происходит.
2 zeo пишет...
Зря вы так про гуглщиков. Кое-то и можно найти: http://www.crossplatform.ru/?q=node/322
Спасибо.
2 Анонимный пишет...
Я думаю, что файловые системы linux (ext-2,3, raser, xfs) при сильной фрагментированности, если возникнет, не настолько теряет производительность
Ребята, это всё СЛОВА и ИМХО. Мне нужны доводы, ссылки и цифры.
2 Шабанов пишет...
http://ols.108.redhat.com/2007/Reprints/sato-Reprint.pdf
Это доклад об онлайн дефрагметации ext4 на Linux Symposium 2007.
О, то что надо! Большое спасибо!
дефрагментация для ext2 нужна, просто всем лень писать дефрагментатор.
Очень сильно фрагментированы частоизменяемые (и частодописываемые) файлы, в частности базы установленных пакетов (rpm, apt). Лично наблюдал, что файлы с этими базами разбиты на десятки и сотни фрагментов (man filefrag)
Пример (на дебиане):
/var/lib/dpkg/available: 10 extents found, perfection would be 1 extent
/var/lib/dpkg/available-old: 13 extents found, perfection would be 1 extent
/var/lib/dpkg/status: 12 extents found, perfection would be 1 extent
/var/lib/dpkg/status-old: 118 extents found, perfection would be 1 extent
-rw-r--r-- 1 root root 1727102 /var/lib/dpkg/available
-rw-r--r-- 1 root root 1727102 /var/lib/dpkg/available-old
-rw-r--r-- 1 root root 1767374 /var/lib/dpkg/status
-rw-r--r-- 1 root root 1767373 /var/lib/dpkg/status-old
/var/lib/rpm/Packages: 59 extents found, perfection would be 1 extent
/var/lib/rpm/Dirnames: 12 extents found, perfection would be 1 extent
/var/lib/rpm/Filemd5s: 15 extents found, perfection would be 1 extent
-rw-r--r-- 1 root root 184320 /var/lib/rpm/Dirnames
-rw-r--r-- 1 root root 659456 /var/lib/rpm/Filemd5s
-rw-r--r-- 1 root root 2379776 /var/lib/rpm/Packages
Файлы небольшие и сильно фрагментированные. Тормоза при установке пакетов заметны невооруженным глазом.
так что ненужность дефрагментации в линуксе - очередной миф.
\\ линуксойд со стажем
Спасибо за http://ols.108.redhat.com/2007/Reprints/sato-Reprint.pdf
Копирую оттуда Conclusion
Online defragmentation for ext4 has been proposed and implemented. Performance measurement has shown that defragmentation for a single file can improve read performance by 25% on a fragmented 1GB file. For relevant file fragmentation, defragmentation resulted in 29% performance improvement for accessing all file in the Linux source tree.
Случайным метателям головок в многозадачной ОС напомниаю, что есть такая штука, как readahead - чтение больше чем заказано во всякие там кэши. Чтобы когда проги прочухаются и попросят исчо, это исчо уже лежало в памяти/кэшах/буферах.
2 Анонимный пишет...
дефрагментация для ext2 нужна, просто всем лень писать дефрагментатор.
Весь вопрос в том, насколько нужна дефрагментация. Это же не NTFS в конце концов.
Очень сильно фрагментированы частоизменяемые (и частодописываемые) файлы, в частности базы установленных пакетов (rpm, apt). Лично наблюдал, что файлы с этими базами разбиты на десятки и сотни фрагментов (man filefrag)
Согласен, по этой причине я для корневой системы использую ReiserFS. Но большое спасибо за такой ценный и развёрнутый комментарий.
Тормоза при установке пакетов заметны невооруженным глазом.
Понятие "тормоза" весьма относительное. Одна и та же версия ОпенОфиса на моей машине под Дебианом обновляется за 20 секунд, а на виндовой машине для этого полчаса мало.
так что ненужность дефрагментации в линуксе - очередной миф.
Разговор идёт про то, что насколько нужна дефрагментация. И так ли она нужна.
2 Анонимный пишет...
Performance measurement has shown that defragmentation for a single file can improve read performance by 25% on a fragmented 1GB file. For relevant file fragmentation, defragmentation resulted in 29% performance improvement for accessing all file in the Linux source tree.
Мда... Похоже на то, что всё-таки нужна. Время от времени.
2 wiz пишет...
Случайным метателям головок в многозадачной ОС напомниаю, что есть такая штука, как readahead
От фрагментации это спасает слабо, хотя производительность несомненно увеличивает.
Ну ладно, уже и умником обозвали, спасибо.
Короче говоря, кто реально ищет информацию, а не подтверждение своим подсознательным мыслям о том, как строятся файловые системы - тот найдёт доки. Если доки искать лень - смотрим в исходник.
Вам не приходило в голову, что статей о фрагментации вы не нашли потому, что проблемы просто не существует?
Про тюнинг ФС - man tunefs, man newfs и подобное - всё там написано.
Можно потратить полдня на то чтобы прочитать Practical File System Design with the Be File System, http://www.amazon.com/Practical-File-System-Design-Be/dp/1558604979
и 90% вопросо отпадут сами, а оставшиеся 10% решатся заглядыванием в исходники.
2 jankkhvej пишет...
Короче говоря, кто реально ищет информацию, а не подтверждение своим подсознательным мыслям о том, как строятся файловые системы - тот найдёт доки.
Я поэтому и попросил знающих людей отписаться в комментариях по теме. Мне интересен вопрос, но рыть исходники у меня банально нет времени.
Вам не приходило в голову, что статей о фрагментации вы не нашли потому, что проблемы просто не существует?
Всё как раз наоборот: находил кучу воплей и вопросов по теме, мало доков и ещё меньше нормальных ответов на вопрос.
По теме: проблема существует, и решения есть. Я об этом напишу обязательно.
Про тюнинг ФС - man tunefs, man newfs и подобное - всё там написано.
В маны посылать это, конечно, сильно :-)
оставшиеся 10% решатся заглядыванием в исходники.
Я спросил у народа в расчёте на то, что кто-то в исходники глядел и потому может простым языком сказать, откуда растут ноги у проблемы. Такие люди совершенно точно есть, и некоторые даже отписались выше.
Ещё раз: если кто найдёт статьи \ ссылки \ посты в блогах по теме фрагментации, буду очень признателен.
to wiz
Знатокам "такой штуки, как readahead" так же напоминаю что "многопользовательская" это не 2 и даже не 3 пользователя. А от сотен до тысяч. Не спасет вас никакой кеш. Напротив, привнесет еще большие тормоза за счет напрасного чтения никому не нужных в следующий момент данных.
Aбсолютно все фс фрагментируются и начинают даже визуально тормозить со временем, т.к. каталоги тоже фрагментируются, а это для readdir очень существенно (в отличии от lookup) - и даже readahead тут не поможет, если следующий нужный блок находится вне readahead-зоны считывания.
По поводу винды: у ntfs драйвера немного дурацкая политика выделения блоков и это приводит к ощутимым тормозам, когда заканчивается место на диске, равно как и c ReiserFS в линуксе. От себя добавлю: линейная дефрагментация (моей экспериментальной программой) дает где-то 10-30% выигрыша в скорости работы с каталогами даже на "нулевом" reiserfs разделе (ясно, что ext2/3 далеко позади), считывание отдельных фрагментированных файлов (типа торрентов) ускоряется на 5-40%
По http://lwn.net/Articles/266274/ можно почитать про эксперимент.
Было записано 32 файла по 1GB. Сначала по очереди, потом одновременно. В последнем случае записи во ФС получилась сильно фрагментированной. Различие в скорости чтения данных составило 14.8% для ext3 и 16.5% для XFS.
О фрагментация файловых систем
Бытует мнение, что файловые системы для OS GNU/Linux не испытывают фрагментации, либо их производительность не сильно страдает от фрагментации, в то время, как стандарт де-факто для систем на базе NT — файловая систем NTFS весьма подвержена фрагментации. Разрешите высказать на этот счет мое мнение, как пользователю и тех и других ОС.
Во-первых, я хотел бы отделить понятия файловой системы, как определенной структуры данных на носителе данных, и, файловой системы, как реализации в ОС этой структуры через сопряженный с ней драйвер и его политики. Драйвер файловой системы по сути является менеджером памяти, обязанным хранить данные на носителе определенным образом. У каждого менеджера памяти есть своя политика выделения места, но есть один общий нюанс. Представим свободное место на носителе, как еще один файл, в котором не хранится ничего. При выделении нового участка у менеджера есть выбор: либо минимизировать число фрагментов свеже-создаваемого файла, либо «файла свободного места». Вот здесь находится главная дилемма всех менеджеров памяти, прямым образом влияющая на фрагментацию данных.
Как может быть вам уже известно, NTFS решает эту дилемму в пользу свободного места — т.е. за милую душу фрагментирует пользовательские данные в надежде, что когда-нибудь «эти проклятые дырки» между файлами в ФС закончатся и пойдет один непрерывный кусок самого настоящего неподдельно свободного места. Все бы ничего, да только пока этот момент наступит именно нужные пользователю данные и фрагментируются.
Драйверы других ФС, главным образом работающих с GNU/Linux или BSD, отдают предпочтение беспощадному кромсанию свободного места, лишь бы не фрагментировать уже созданные файлы. Особо умные (Ext4 и те, с кем не знаком) еще и занимаются интеллектуальным выделением экстентов к файлам, чтобы — да *** с ним, со свободным местом, - не дай бог не фрагментировать важные пользователю данные.
Как следствие этих двух подходов, фрагментация данных на разных ФС отличается соответственно. Другой вопрос — страдает ли производительность от фрагментации файлов. Мое мнение такого, что да, страдает. Причем зависимость совершенно прямая. Другое дело, что Ext*,ReiserFS и иже с ними фрагментируют одно, а NTFS — другое. Причем не сама ФС, а именно конкретная ее реализация в виде конкретного драйвера под конкретную ОС с конкретными «зашитыми» в него политиками выделения места под файлы. Надеюсь в NTFS3G эти политики поменяли, иначе «энтээфэс капут».
Отдельного внимания заслуживает эксплуатация ФС. Для сравнения приведу два крайних примера — корневая ФС в GNU/Linux и временной каталог download manager'а (например eMule + сжатие файлов на NTFS). На крайне редко изменяемых ФС выбор типа ФС из склонности к фрагментированию непринципиален, а вот на крайне динамично изменяемых этот вопрос очень даже актуален. Под NTFS динамично изменяемые места ФС призодится выносить на отдельный раздел (как /var и /tmp), вот только их использование тем же eMule в сочетании со встроенным сжатием — (иначе нельзя — места на диске не напасешься) — самая наиполнейшая «жесть». Тут возможно в вопросе фрагментации завалится любая ФС, просто все (кроме NTFS — ей понравится, попросит ещё) будут по-разному сопротивляться.
Не знаю как насчет других дистрибов... но до меня дошли слухи о том, что в debian-дистрибутивы заложено авто-дефрагментирование или что то вроде того...
Сам я на лине сижу порядка 2 месяцев, пока тормозов не заметил...
Задался тем-же вопросом, в процессе гугления нашёл интересную статью Дефрагментация - польза или вред?
Дефрагментатор нужен в случае если система стоит на виртуальном диске vmware с динамически изменяемым размером. Vmware умеет обрезать файлы виртуальных дисков, но только в случае если диск дефрагментирован. Короче, дефрагментация - это способ борьбы с ростом файла виртуального диска.
Насколько мне известно с выходом SSD дисков проблема дефрагментации плавно перетекает в проблему случайной записи по разным ячейкам памяти, так как головка уже не бегает по диску и производительность не снижается. Так что проблема уже не актуальна - её можно решить аппаратными средствами.
Ага, можно решить _новыми_ аппаратными средствами, т.е. за деньги, и не маленькие :)
> StraNNicK
жизненное наблюдение сводится к следующему: "когда коту нечем заняться, он вылизывает яйца. Когда нечем заняться пользователю windows, он дефрагментирует диск"
Можешь еще штаны не снимать, когда срать захочешь. Просто потом придется купить новые. Также и с диском.
Как интересно!
Анонимусы не знают о существовании стирки и искренне полагают, что если не проводить дефрагментацию - диск испортится. :D
Нобелевка по вам плачет. Горькими-горькими слезами.
df -h /dev/sdb1
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sdb1 932G 773G 159G 83% /mnt/data2
xfs_db -c frag -r /dev/sdb1
actual 561370, ideal 85577, fragmentation factor 84.76%
Это после недели работы торрента. В выходной - дефраг до 10-20%, через неделю - см. выше.
Нужна дефрагментация, ой как нужна... У меня и амуля и торренты постоянно концентрируют на винте тьму файлов - это просто ужас какой-то... - настолько падает скорость при любых операциях копи-паста-записи на двд, или заливки на сервера по лану... И этот фактор - единственный, который серьезно нервирует в Лине... (4 года ubuntu user)
здесь многие говорят,что фрагментация почти не влияет и что она очень мала
нифига себе,ьлин,мала и не влияет!
у меня после 8 месяцев фрагментация на винде была 29% и это очень сильно раздражало - всё долго делает и тупит(ещё и потому,что это винда)
окончательно убил некрософт на своём компе и несколько месяцев скитаюсь по системам - помогли,ставьте Дебиянь,классная система
собственно поэтому темой и заинтересовался
спасибо всем за ответы,всё понятно
Файловую систему без фрагментации файлов практически не создать, разве что убрать фрагментацию файлов и оставить фрагментацию диска. Но тогда свободное место быстро кончится :(
Если дефрагментировать на лету, то это также может создать нагрузку на диск, т.к. все равно придется ворочать по диску что-то тяжелое, передвигая туда-сюда.
Остается подождать, когда SSD-диски будут дешевыми, тогда систему и торренты можно установить на них, а ЖД оставить под хранилище ценных данных.
(я создал два раздела ext3 одной емкости и периодически в Ubuntu LiveCD полностью переношу информацию с одного на другой, форматирую источник и возвращаю данные. Получается достаточно "быстрая" дефрагментация для небольшого раздельчика)
@Анонимный комментирует...
я создал два раздела ext3 одной емкости и периодически в Ubuntu LiveCD полностью переношу информацию с одного на другой, форматирую источник и возвращаю данные. Получается достаточно "быстрая" дефрагментация для небольшого раздельчика
Специально для таких как вы и придумали LVM. Не нужно постоянно держать два раздела: в нужный момент создаём второй раздел и копируем в него содержимое первого. Теперь удаляем первый раздел и используем заместо его полученный. Делается это без всяких LiveCD, не отрываясь от работы на любимом Debian/Ubuntu. Кстати, я тут пытаюсь установить LVM и накатить на него Ubuntu. Скажу, что это тема отдельного поста, идею которого хочу предложить virens'у (и в Debian и в Ubuntu делается всё одинаково). С радостью поделюсь наработками.
@iv_vl комментирует...
Специально для таких как вы и придумали LVM.
В LVM отпугивает его хрупкость: если что-то случится с диском (появится несколько bad sectors), есть риск потерять сразу все данные. Во всяком случае мне доводилось натыкаться на форумы с плачами Ярославны на тему "не могу достать свои данные из элвээма НИКАК!".
Кстати, я тут пытаюсь установить LVM и накатить на него Ubuntu.
К тому же это и не так просто, как кажется. Мне тут Анонимусы в своё время на LVM намекали и неистово его пиарили, но я покамест остаюсь на старом-добром разбитом корыт^W винчестере с вручную разбитыми разделами.
Скажу, что это тема отдельного поста, идею которого хочу предложить virens'у
iv_vl, я обеими руками за. Просто у меня нет твоих координат - если всё ещё читаешь комменты, напиши мне письмо на mydebianblog джымайл ком - вышлю приглашение в тестовый блог, и ты сможешь там выдать пост. Я в общем заинтересовался.
Linux в отличие от Windows не обязательно записывает обновленный файл поверх старого, при записи во избежание фрагментации выбирается место чтобы он влез полностью. Поэтому то в этой системе нет программ дефрагментаторов, мне доводилось видеть фрагментацию данных максиум 0.5 %, да и то на переполненном диске, что согласитесь очень мало.
Одно дело теория а другое - практика.
Сейчас диски выросли и 1Тб сейчас не проблема,
однако в плане хранения это много и дефрагментация потребует ПРОРВУ времени, а она может потребоваться. В мою бытность, одна чудо-программа хранила журнал IP трафика проходящего через роутер в postgres базе (кроме журнала там еще много что хранилось). Соответственно оно росло и каждый день удалялись записи предыдущих дней. В результате раздел с xfs так потерял в производительности что доступ к этой базе был десятки секунд, да и просто открытие каталога содержащего postgres базы занимала десяток секунд. Так и мучался не имея возможности дефрагментировать тормозящую продакшн систему. В итоге смонтировал в хранилище баз данных каталог по samba и все данные жили на отдельном компьютере. В случае очередного падения производительности технология позволяет их перенести еще и работать далее. Даунтайм получается ничтожный.
Разочаровался я с тех пор в xfs.
Отправить комментарий
Подписаться на RSS-ленту комментариев к этому посту.