Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 3 След.
RSS
Дефрагментаторы в Linux.
 
Я работаю с Linux около 5 месяцев. Раньше, в Windows, когда винт  (Samsung SpinPoint) начинал издавать звуки, похожие на треск и немного притормаживать, я понимал, что пора делать дефрагментацию. Теперь, в Linux, я столкнулся с той же проблемой - система работает медленнее чем раньше, а винт (при нормальных обстоятельствах его вообще не слышно) с каждым днем трещит все сильнее. На всех разделах, у меня ext3, а на разделе boot - ext2. Сначала може показаться, что хреново дело с винтам, а не с фрагментами файловой системы, но в нем я уверен на все сто процентов, так как для установки Linux (RadHat 8.0) я покупал новый винт и в его работоспособности не сомневаюсь. Может кто-нибудь подскажет в чем тут дело.
 
дело точно не в дефрагментации... к тому же симптоматика
Цитата
"Теперь, в Linux, я столкнулся с той же проблемой - система работает медленнее чем раньше"
вряд ли описывает "железные" проблемы.

а [quote]с каждым днем трещит все сильнее[/qoute] звучит как проблемы с винтом...
 
Понил!
 
Мне всетаки интересно: есть ли хоть оди дефрагментатор для линукса. Просто хочу проэксперементировать, что получится?
Может девелоперов расшатаем, авось напишет кто какой-нить простенький дефрагментатор.  
 
Цитата
Freiheit пишет:
Мне всетаки интересно: есть ли хоть оди дефрагментатор для линукса. Просто хочу проэксперементировать, что получится?
Может девелоперов расшатаем, авось напишет кто какой-нить простенький дефрагментатор.  
Есть. Погугли.
 
В инете я могу нормально сидеть только на работе(чего щас вместо работы и делаю ;) ), а дома, искать на модеме очень напряжно, но все равно спасибо за совет.
 
Был такой проект на уровне экспериментального - e2defrag. Кстати, проверить фрагментацию можно командой e2fsck -n /dev/sda_сколько_у_тебя_там. Только он считается довольно небезлпасной. Насчёт ext3 - не скажу - наверняка там всё то же самое - ибо отличается только ведением файла журнала (и то при задании условий).
 
Когда меня послали на гуглю, я так и сделал. Вообще много нового узнал по поводу дефрагментации, и особенно в линуксе. Большенство сайтов и статей говорят, что линуксу не нужна дефрагментация. Некоторые говорят, что дефрагментация вредна, а особенно для серверов, где каждый файл постоянно может изменяться. Там также объяснялось, что дефрагментация, если хотябы один раз ее сделать, будет порождать еще более сильную фрагментацию последующих изменяемых файлов (особенно на серверах). Поэтому рекомендуется смирится со слабой фрагментацией без дефрагментации вообще, или постоянной дефрагментацией сильно фрагментированных файлов в результате дефрагментации ((???) Извините за тавтологию). Короч дефрагментатор я нашел (O&O Linux Defrag если не ошибаюсь). Но всетаки я про это ничего не понял. Может кто поделится мыслями по этому поводу
 
Есть основания не доверять всему вышепроцитированному?
 
Блин, ну не нужен в Линуксе и прочих Юниксах дефрагметатор. Хоти поизвращаться? - тогда lvm, soft raid в руки.
 
Насколько мне известно, дефрагментаторов под Linux нет по определению. ext2(ext3) так устроины, что их дефрагментировать не надо.
 
Когда появилась NTFS, все тоже говорили, что она не фрагментируется благодаря супермаленькому размеру кластера.
 
Цитата
Kalashmat пишет:

Блин, ну не нужен в Линуксе и прочих Юниксах дефрагметатор.
Почему это не нужен?
Любой НЖМД дает до 60МБайт/с и даже больше при линейном чтении с внешних дорожек и на порядок меньшую скорость при произвольном чтении, ввиду затрат на перепозиционирование над дорожкой и время на позиционирование блока головок над необходимым сектором(latency).
Поэтому на любом НЖМД чтение/запись расположенных линейно расположенных данных(чему препятсвует фрагментация) намного быстрее чтения раскиданных по всему диску фрагментов и файлов.
К тому же, график чтения/записи на практически всех дисковых НЖМД имеет вид "ступенька", линейная скорость чтения/записи в начале диска(на внешних дорожках) в два, а то и более раз превосходит скорость на внутренних дорожках.
Поэтому дефрагментация, что по сути есть оптимизация расположения файлов непрерывными блоками ближе к началу диска(внешним дорожкам), при чем обычно нормальными дефрагментаторами к началу диска перемещаются наиболее часто используемые данные, сокращает количество и время перепозиционирований, увеличивает процент линейного чтения/записи - весьма повышает производительность файловой системы, хотя и может иметь непродолжительный эффект, который зависит от интенсивности изменения данных.
Например, перенос своей генту с hda4(раположенный за 65 гигабайтом 80-гигового 7200RPM винта, линейная скорость менее 30 МБайт/с) на hda3(к-рый расположен начиная с 600-го мегабайта, линейная скорость около 55МБайт/c), при чем по сути произошла дефрагментация с подтягиванием файлов к началу диска, _существенно_ увеличил скорость работы файловой системы, что очень заметно даже на глаз.
Чем меньше оборотов в минуту(RPM) совершает привод блока дисков накопителя, а значит больше latency при подлете БМГ(блока магнитных головок) к необходимому сектору, тем он медленнее при чтении фрагментированных данных и тем серьезнее влияние фрагментации файловой системы на его производительность - на скорость файловой системы на 4500RPM винтах дефрагментация оказывает существенное влияние, на 15000RPM винты - практически незаметное...
Для десктопа(где данные изменяются существенно меньше, чем на серверах) дефрагментация не только не вредна, но и наоборот - полезна и эффект она обеспечивает достаточно длительный.
 
2 r00t

Цитирую:
Сегодня уже есть целый ворох дефрагментаторов для различных ОС и файловых систем и регулярно появляются новые. Собственно поводом к написанию данной статьи послужил выпуск программы O&O Defrag Linux. Конечно, судить о конкретных достоинствах и недостатках по бета-версии некорректно, но, как мы попытались объяснить выше, вопрос стоит гораздо шире -- зачем вообще нужен дефрагментатор в системе, где выгода от его использования практически неуловима? Да, дефрагментация и в Linux может оказаться полезной в случае однопользовательской "однозадачной" настольной системы, особенно работающей с потоковыми данными. Но даже в этом случае вполне можно положиться на собственные механизмы "умной" файловой системы, со своей стороны помогая ей избегать фрагментации: оставлять достаточно свободного места на диске, хранить редактируемые данные в отдельном разделе и пр.

Подобные программы существуют постольку, поскольку на них есть спрос. Спрос же частично объясняется тем, что пользователи привыкли к тому, что подобные приложения необходимы для нормальной работы компьютера. Кроме того, некоторым подсознательно нравится, когда умное (с их точки зрения) ПО сообщает, что с компьютером все в порядке. Уровень интеллекта и диапазон возможностей среднего современного дефрагментатора значительно ниже, чем у аналогичной разработки эпохи DOS (кто-то вспомнит старый добрый Norton SpeedDisk и будет прав). Сегодня подобные программы (отнюдь не только дефрагментаторы) существуют больше как антидот от болезней пользователя, нежели компьютера.

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

<a href=http://www.all-win.ru/modules.php?name=Articles&pa=showarticle&articles_id=221 rel="nofollow" target="_blank">Источник</a>

Вот и думай, друг юзал Слаку более 2-х лет и пока ее не снес даже не запаривался о дефраге, а тем более на серверах, вообще бред.
 
Ну так юзеры многие вообще ни о чем не запариваются, ни о возможности разгона, ни о возможности оптимизации и тп, я тоже привел аргумент - фактическую дефрагментацию генты, что дало весьма серьезный эффект, при чем я аргументированно объяснил почему это дало такой эффект.
Хотя бы за счет подтягивания наиболее часто используемого файла с внутренних дорожек ко внешним(началу диска) увеличвает скорость его считывания в два и более раз, при чем чисто проивзольного доступа у файловой системы нет - за счет апапратного и программного префетча, когда считывается требуемый сектор и следующие за ним - обычно от 8 до 32 секторов аппаратно винтом в свой кеш:
$ sudo hdparm -I /dev/hda3|grep ahead
            *    Look-ahead
и обычно от 64 до 256 секторов в дисковый кеш операционной системы).
$ sudo hdparm /dev/hda3|grep ahead
readahead    = 256 (on)
 
to Kalashmat
Я эту же статью читал, , может подскажешь какое-нибудь еще место.
 
Цитата из интервью разработчиков ASP Linux:

TanaT: Это правда, что для файловой системы Linux не существует такого понятия как дефрагментация? Ведь в Windows дефрагментацию рекомендуется проводить регулярно.

Кирилл Конягин: Правда. Так устроена файловая система - при записи файлов она по возможности записывает их непрерывно. Тем не менее, фрагментация файлов во всех современных файловых системах (NTFS 5, Ext2, Ext3, XFS и т. п.) присутствует, но она не принимает таких серьезных масштабов, как, например, в FAT. Поэтому дефрагментация не является жизненной необходимостью, но иногда (довольно редко) бывает целесообразна. Все необходимые инструменты для этого у каждой файловой системы есть.

<a href=http://www.fcenter.ru/online.shtml?articles/software/interview/6924 rel="nofollow" target="_blank">Источник</a>
 
Эти утверждения не отрицают необходимости дефрагментации, более того даже утверждают что она иногда нужна:

Цитата
Kalashmat пишет:

Да, дефрагментация и в Linux может оказаться полезной в случае однопользовательской "однозадачной" настольной системы, особенно работающей с потоковыми данными. Но даже в этом случае вполне можно положиться на собственные механизмы "умной" файловой системы, со своей стороны помогая ей избегать фрагментации: оставлять достаточно свободного места на диске, хранить редактируемые данные в отдельном разделе и пр.

Цитата
Kalashmat пишет:
TanaT: Это правда, что для файловой системы Linux не существует такого понятия как дефрагментация? Ведь в Windows дефрагментацию рекомендуется проводить регулярно.

Кирилл Конягин: Правда. Так устроена файловая система - при записи файлов она по возможности записывает их непрерывно.
Для Linux также отсутствует такое понятие как современные игры, 1С, Фотошопа и прочего - но это ведь не означает что они никому не нужны? Такая же ситуация и с программами дефрагментации.

А теперь внимание:
Цитата
Kalashmat пишет:

Тем не менее, фрагментация файлов во всех современных файловых системах (NTFS 5, Ext2, Ext3, XFS и т. п.) присутствует, но она не принимает таких серьезных масштабов, как, например, в FAT. Поэтому дефрагментация не является жизненной необходимостью, но иногда (довольно редко) бывает целесообразна.
Да, и именно из-за того, что дефрагментация файловой системы NTFS5 не нужна, в ОС Windows XP и W2k3 реализована включенная по умолчанию функция Boot Defrag, которая постоянно оптимизирует расположение системных файлов(а кто-то не знал?), в частности поэтому, а также из-за параллельного запуска сервисов, винда и загружается как электровеник.

Kalashmat
Если смысл моих предыдущих постов(которые не были взяты из гугля) неясен, то резюмирую: важна не только непрерывность расположения файлов(отсутствие фрагментированности файлов), НО и их расположение на поверхности диска, а процедура дефрагментации не только дефрагментирует файлы, но и оптимизирует их расположение на диске, что дает прирост в скорости при обращениях к данным файловой системы!
Если сможете, то аргументированно докажите, что дефрагментация(которая на самом деле является не только процедурой сборки фрагментов, но еще и оптимизацией расположения файлов для увеличения быстродействия) абсолютно не нужна в следующем реальном примере.
Итак, скорость линейного чтения в начале диска 55МБайт, скорость чтения на внешних дорожках - 25МБайт/с(реальные цифры для IDE-винта), машина - Linux десктоп. Наиболее часто используемые данные и редко изменяемые исполнимые файлы раскиданы по всей поверхности жесткого диска, что приводит к большим накладным расходам на перепозиционирование при доступе к ним(затраты на перепозиционирование БМГ тем выше, чем больше расстояние между  дорожками, содержащими данные + расходы на latency), ввиду эксплуатации образовалось множество незанятых блоков файловой системы(т.к. файловая система пытается располагать данные непрерывными блоками при наличии свободного места), поэтому данные расположены очень некомпактно, что приводит к падению линейной скорости в два раза и более на внешних дорожках по сравнению со скоростью на начальных дорожках.
После фрагментации наиболее часто используемые программные файлы расположены в начале диска(линейная скорость ~50 Мбайт/c), далее идут менее используемые файлы и далее расположены часто изменяемые файлы(идут одним блоком, поэтому затраты на перепозиционирование минимальны), в на внешних дорожках, в конце диска расположены очень редко используемые данные и программы(поскольку скорость их считывания мало кого волнует).
 
2r00t
Offtop on
Вы что-то пытаетесь доказать?
У вас с этим проблемы?
Хотите поговрорить об этом?
offtop off

А теперь по делу: к счастью я не страдаю параноей и нерадуюсь от мысли, что после дефрагметации у меня будет быстрей загружаться система. И уж извините что я смотрю со своей "колокольни" обслуживая сервера начиная от HP-UX кластеров до простых Linux мыльников которые работают по формуле 24x7 и дефрагментация на них абсолютно бессмысленна, а во многих случаях просто губительна. Неотрицаю, что сама дефрагментация возможна, но более-менее серьезной статьи даже в гугле (кроме ваших субъективных умозаключений) я ненашел, а посему ваши посты не из гугля :) лишь ваши домыслы и не более.
 
Цитата
Kalashmat пишет:

И уж извините что я смотрю со своей "колокольни" обслуживая сервера начиная от HP-UX кластеров до простых Linux мыльников которые работают по формуле 24x7
К чему Вы это говорите? У меня тоже есть пяток серверов, работающих строго в режиме 24/7 и есть кое-какие  представления о железе после изучения низкоуровнего программирования железа на ASM/C и после работы в компьютерном сервис-центре, где помимо прочего занимался иногда восстановлением винтов с помощью PC3000.
Естественно, я не занимаюсь ерундой и никому не советую регулярно дефрагментировать диски серверов, данные на которых постоянно изменяются, тем более, если они находятся под нагрузкой 24/7, хотя бы потому, что такая оптимизация расположения файлов после дефрагментации все равно имела бы непродолжительный эффект, да и существуют намного более важные, нежели дефрагментация, дела либо безделье )))

Цитата
Kalashmat пишет:

и дефрагментация на них абсолютно бессмысленна, а во многих случаях просто губительна.
Вообще, топик изначально не ограничивался *nix серверами. В своих постах я несколько раз указывал, что речь идет десктопе, в т.ч. о *nix десктопе - бывают и такие.

Насчет губительности, когда-то я задавал вопрос инженерам Maxtor насчет губительности дерагментации, вот что мне ответили:

Dear ******** ******,

Thank you for your email.

When you save a data file to your hard disk, the operating system will try
and store the complete contents of the file to the same section of the hard
disk. Once the disk starts to become full, this process becomes impossible
to achieve and the operating system splits the contents of the file over
sections of the disks - the files become fragmented. Defragmentation is a
utility that you can run over your hard disk to put the defragmented files
back together.

So an defragmentation should not harm your hard disk.

If you need any further help please do not hesitate to contact us.

Kind Regards,
Ulrike Bubl
Technical Support Team, Maxtor Ireland Ltd.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=
|         MAXTOR Technical support / customer  Service          ;       |
+----------------------------------------------------------- --------+
| MAXTOR Ireland Ltd      | Phone   ++353 1 204  1111         &n bsp;      |
| Bray Business Park      | Fax     ++353 1 286  1419         &n bsp;      |
| Southern Cross Rd, Bray | Faxback ++353 1 204  1122         &n bsp;      |
| Co Wicklow, Ireland.    | E-mail  eurotech_assistance@maxtor.com  |
| VAT No. IE 6564121M     |  WWW:    http://www.maxtor.com &nbsp ;         |
|           ;           ;     |   FTP:    ftp://ftp.maxtor.com &nbsp;            |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=

-----Original Message-----
From: ********@******.*******.ru [mailto:********@*****.*****.ru]
Sent: 24 February 2002 23:52
To: eurotech_assistance@maxtor.com
Subject: Disk defragmentation related question

 ************************************************************ ********
 ********************** Submitter Details ***************************
...
 ********************** Support Request Details **********************
 Location: Europe
 Language: English
 Request Type: Technical
 Manufacturer: Maxtor
 Drive Model: Maxtor 5T020H2
 Product Line: ATA/IDE Drive
 Product Serial #: ********
 Product Part #:
 Operating System: Windows XP   Version: 5.1.2600
 Computer System: Celeron 500/i810/256RAM/2x20GB
 CPU: Other
 CPU Speed: 500 MHz
 Controller Card: none


 ********************** For SCSI Products ****************************

 SCSI Adapter:

 Description:
 Is intensive defragmentation safe to the hard disk drive health?




Цитата
Kalashmat пишет:

Неотрицаю, что сама дефрагментация возможна, но более-менее серьезной статьи даже в гугле (кроме ваших субъективных умозаключений) я ненашел, а посему ваши посты не из гугля :) лишь ваши домыслы и не более.
Поправлю - аргументированное обоснование, с приведением реальных цифр и на основе реально полученных положительных результатов оптимизации разных файловых систем на десктопах.
Те цитаты, которые приводили вы, пытаясь также что-то доказать, не несут практически никакой аргументации, а основываются на субъективных представлениях кого-то там и на очень идеализированной модели дефрагментации, в которой не учитывается, что дефрагментация не только дефрагментирует, но и перераспределяет данные, там не учитываются зависимость линейной скорости от расположения данных на диске и не учитываются накладные расходы на перепозиционирование БМГ.
Страницы: 1 2 3 След.
Читают тему