ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Kirill Frolov                        2:5030/827.2   08 Dec 2003  17:00:53
 To : Valentin Nechayev
 Subject : Re: дефрагментация ex3
 -------------------------------------------------------------------------------- 
 

 
 On Sun, 07 Dec 03 13:30:00 +0300, Valentin Nechayev wrote:
 
  VN> Ты скажи простую вещь - а накойхер его копировать в /dev/null?
  VN> Впрочем, если это единственная задача этого тазика - копировать фильмы
  VN> в /dev/null - я, пожалуй, соглашусь с тем, что ему регулярно нужна
  VN> дефрагментация;))
  VN> А какую-то... мнэээ... более реальную задачу ты можешь описать?
 
    Я уже писал в предыдущих письмах, что для реальных задач это всё не
 слишком принципиально. Тем более, что /var всё остальное в разных
 файловых системах располагается. "Фрагментация есть, и она влияет, но
 не настолько, чтобы об этом беспокоиться".
 
  AB>>> А при записи все будет записано не в логическом порядке, а по
  AB>>> поступательному движению головок.
  KF>>    Тем не менее, логический порядок в пределах некоторой группы секторов
  KF>> соблюдается.
  VN> Я уже рассказывал тут, что в ufs файл намеренно разрывается на несколько
  VN> полос, драйвер устанавливает предел, сколько в одной полосе может быть
  VN> записано данных из одного файла.
  VN> Попробуй узнать, почему они так сделали - найдёшь много интересного
  VN> для себя. (Меня не терзай вопросами по этому - было слишком давно)
 
    Hо там есть как верхний, так и *нижний предел*!  И блок пишется в
 группу из нескольких секторов, и смежные блоки записываются рядом...
 
  KF>> порядка 8-11мс). Только вот не стоит забывать, что сектора записаны
  KF>> последовательно, и время поиска при последовательном-же чтении там -- 0.
  VN> У них достаточно много шансов быть записанными с неединичным интерливом.
  VN> Для некоторых дисков это принципиально.
 
    Ещё раз: сектора или физически так размещаются, или трансляция так
 реализована, чтобы задержки были минимальны. Это тот-же HDD-SPEED и
 демонстрирует. Что касается переназначения секторов, то для кащенитов,
 вроде Барабанова, замечу, что сектора переназначенные ещё на заводе
 практически не влияют на время последовательного чтения, что опять-же
 демонстрируется всё той-же программой HDD-SPEED (такие сектора
 переназначаются в следующий за ним, а не в другой конец диска).
 
  AB>>> Вот поэтому все _взрослые_ дяди, как только были придуманы и внедрены
  AB>>> системы элеватоного чтения/записи, перестали заниматься алгоритмами
  AB>>> дефрагментации.
  KF>>    БРЕД. ПОЛHЕЙШИЙ. Размещение секторов "через один" (сектор, блок -- не
  KF>> важно) уже даст падение скорости чтения В ДВА РАЗА.
  VN> А при чём тут размещение "через один" к лифтовому оптимизатору?
 
    А причём тут лифтовой оптимизатор к фрагментации?
 Фрагментация есть, и она влияет, пусть и не слишком значительно.
 Утверждать обратное -- невероятно глупо.
 --- [ZX]
  * Origin: Registered Linux User #204355 (2:5030/827.2)
 
 

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