Главная страница


ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     19 May 2003  23:49:07
 To : Sultan Azhiguzhayev
 Subject : Re: defrag
 -------------------------------------------------------------------------------- 
 
 
    Hi, Sultan!
 
 >>>>> "SA" == Sultan Azhiguzhayev <Sultan.Azhiguzhayev@f84.n5083.z2.fidonet.org>
 >>>>> writes:
 
 [skip]
  VB>>  Ты поинмаешь, что запись файла будет происходить бустрее, если его
  VB>> будет писать в ближайший к головкам сектор, а не в конце файла, да?
  
  SA> а если там мало места, а ближайший свободный кусок находится фиг знает
  SA> где?
  
  вывод 1 - держим на винте место "с запасом".
  
  
  VB>> А где у нас в произвольный моент времени головки?  Учитывая что
  VB>> всякие syslog'и пишут логи, cron'ы выполняют задания, почтовки
  VB>> принимают почту, и ваще свапер вытесняет ненужные страницы памяти на
  VB>> диск.
 
  VB>>  Ту-же логику примени к чтению.
  
  SA> кэш чтения/записи?  по-моему, неплохо было бы если б вещи делались
  SA> разумно.
 
  мысль 1 - кешатор дисков на линуксе вполне разумный.  Иногда даже слишком
            разумный :))
            
            
  VB>>>>   Допустим у меня пять разделов, с ext3/reiser/xfs,
  VB>>>> на которых фрагментация составляет от 1% до 5%.
 
  SA>>> ну это пока... но "энтропия системы постоянно растет и весь мир
  SA>>> погибнет..." :)
 
  VB>>  в моеё вселенной я не видел фрагментации ext2 более чем 5%.
  SA> чем оценивал? :) 
  
  при кадом монтировании по загрузке системы пишут.  
  
  
  SA> таки интересует проблемка? :)
 
  У меня интерес к файловым системам еще с момента перехода на HPFS, а потом
  на HPFS386, у которой по мимо более грамотного кешатора (в сравнении с
  hpfs) еще и статистика выдавалась какая-никакая (по поаданиям в кеш), и
  возможности "более тонкой настройки" были.  С тех пор интерес поугас (мне
  теперь дешевле необходимую производительность получить экстенсивным
  путем), но за некотоыре цифры "глаз цепляется".
  
 
  [skip]
  
  SA>>> восстановление производительности операций чтения/записи.
 
  VB>>  еще раз - зависимость производительности от дефрагментации в студию.
  
  SA> скопируй пару фильмов на сильнофрагментированную fs и на
  SA> свежемороженную.  да и субиде всякие при фрагментации (у них слава
  SA> богу свои средства борьбы есть) несколько "проседают"
 
  возвращаемся к "вывод 1" и твоему вопросу в предыдущем письме - да, у меня
  на диске почти всегда есть свободного места столько, чтоб туда легко влез
  "средний мой файл".  
  
  В итоге, драйвер fs может более оптимально записать данные, с учетом того,
  что их будут читать, а кешатор диска, позволяет реальной записи на диск
  происхдить еще более оптимально, переставляя в очереди запросов на запись
  блоки так, чтоб уменьшить количество long seek.
  
  Т.е. за мои годы использования linux и ext2/3, у меня не возникало мысли о
  том, чтоб увеличивать поизводительность дисковой подсистемы путем
  дефрагментации файловых систем.
  
  Даже на OS/2 я запускал дефрагментатор "чисто по приколу".  Кроме того,
  насколько я помню всякие статейки про hpfs, там говорилось что файл
  лежащий в двух-трех экстентах в среднем читается быстрее, чем тот, который
  лежит одним куском.  Аргументов не помню, но были они весьма убедительны :))
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 Re: defrag   Vladimir Bormotov   19 May 2003 23:49:07 
 defrag   Sultan Azhiguzhayev   20 May 2003 20:25:06 
Архивное /ru.linux/25416c9efe6b.html, оценка 2 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional