ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     15 Jan 2001  13:51:31
 To : Alexander Pevzner
 Subject : Re: Проги для дефрагментации   ?
 -------------------------------------------------------------------------------- 
 

 
    Hi, Alexander!
 
 >>>>> "AP" == Alexander Pevzner <pzz@pzz.msk.ru> writes:
 
 [skip]
 
  AP> В общем, я хочу сказать, что на дектопе параллельная работа нескольких
  AP> процессов с файлами происходит очень редко, и если уж выбирать, то
  AP> дектоп стоит оптимизировать под эффективную работу одного процесса с
  AP> диском.  В отличии от сервера.
 
  все может быть... Хотя лично я бы расчитывал на "два-три процесса, как
  минимум". 
  
 VB>>  в итоге, мы получаем _пиковую_, но таки нагрузку. И опять-же, самым
 VB>>  узким местом дисковой подсистемы в данной нагрузке тут является Long
 VB>>  Seek.
 
  AP> Для дектопа не важно поведение при пиковой, но кратковременной
  AP> загрузке.  Оно почти не воспринимается человеком. 
  
  в целом да.
  
  AP> Гораздо важнее, сколько времени длятся долговременные операции.
 
  Опять-же, если она не блокируется.
   
 VB>>  пары мыслей, которые могут вообще ничего не утверждать:
 VB>> - если у меня send-mail большой, и весь одним куском, сколько операций
 VB>>     чтения с диска нужно чтоб в него _дописать_ письмо?
 
  AP> Это у тебя просто памяти мало :-)
 
  Конечно. "Памяти много не бывает" ;))))
  
 VB>> - какова вероятность того, что "расстояние" от хвоста send-mail до того
 VB>>     места, куда запишут задание в очередь меньше
 VB>> a) нефрагментированой ext2
 VB>>       б) ext2 на которой файлы "записывались так, как получалось" (в
 VB>>       смысле ее просто никто никогда не фрагментировал)
  
  AP> Дефрагментация, которая дефрагментирует не только файлы, но и пустое
  AP> пространство, должда давать эффект: если все файлы сложены в кучку,
  AP> переход между ними будет быстрее.
 
  Да, но в случае записи, будет LongSeek, на пустое место через всю кучу
  файлов. 
  
  Т.е. мы опять таки пришли к тому, что нужны _цифры_, которые даже тестово
  получить весьма нетривиально, не говоря уже о "оценить просто подумав".
  
  AP> Далее, при последовательном доступе к файлам из нескольких
  AP> параллельных процессов тоже может быть некоторая польза от
  AP> дефрагментации. Если программа успевает пережевывать данные с той
  AP> скоростью, с которой они считываются с диска, есть шанс, что несколько
  AP> последовательных запросов будут обрабатываться одной серией. 
  
  В случае дефрагментированой fs, особенно как ты говорил "файлы одной
  кучей, свободное место - другой, нот оже одной кучей", получаем что это
  верно для однотипных запросов. Т.е. или "все читают", или "все пишут".
  Как только один процесс читает, а второму нужно что-то записать -
  LongSeek через пол диска.
  
  Кстати, вот в HPFS считалось оптимальным хранить файл в 3-4 кусках.
  Уж не знаю как там IBM (или кто-то еще) подсчитал статистику, но...
  
  AP> Это эффективнее, чем кормить каждую программу по одному блоку данных,
  AP> перебрасывая каждый раз головку через полдиска.
 
  да, но... В общем, нада заминать, я же говорю - смаковать это можно
  долго...
  
  Кто-бы вот написал скажем статистику к ядру, по использованию файловых
  систем, кеша...
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

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