ru.linux

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

 
 On Sun, 07 Dec 03 12:56:45 +0300, Aleksey Barabanov wrote:
 
  AB>> Если что-то на диске стоит не порядке последовательного чтения, то
  AB>>  после AB> первого чтения, произведенного с упорядочиванием блоков в
  AB>>  порядке AB> поступательного движения головок, и записи этого в кеш это
  AB>>  уже вполне AB> линейно.
  KF>>    Для этого в линухе кэш нужен на 40Гб, так?
  AB> Сначала "сферический видеофильм", теперь "сферический файл" размером в 40Г
  AB> ;)
 
    Hет, просто чтобы "после первого чтения, произведённого с
 упорядочиванием блоков в порядке поступательного движения головок (ну не
 бред-ли?) и записи в кеш линейно (а для RAM это важно?)" -- HУЖЕH ОЧЕHЬ
 БОЛЬШОЙ КЭШ, как и "аптайм".
 
  AB> Клиническая картина усугубляется ;)
 
    Угу. Как таких как Вы, только из кащенки выпускают...
 
  >> участок диска для любого IDE накопителя элементарно замераяется
  >> программами вроде HDD-SPEED и составляет единицы-десятки миллисекунд.
  AB> О ! Я правильно определил, что "ноги" у бреда "растут" из ДОС ;)
 
    Предложите ваш способ замерить время доступа.
 
  >> порядка 8-11мс). Только вот не стоит забывать, что сектора записаны
  >> последовательно, и время поиска при последовательном-же чтении там -- 0.
  AB> --^^^^^^^^^^^^^^^^^^
  AB> Изучаем матчасть. Уточняем "последовательно" как ? В логической
  AB> последовательности, в физической ? Вспоминаем о существовании в IDE еще и
 
    И в той, и в другой одновременно. Так любой накопитель устроен, что
 последовательная запись в логическую "геометрию" приводит к
 последовательной-же записи в физические сектора.
 
  AB> таблицы автоматической замены поврежденных секторов.
 
    А вы эту таблицу видели?  Там этих секторов и дорожек, относительно общего
 объёма, не так уж и много. 
 
  AB> Вспоминаем еще и о том, что эта таблица заполнятся начинает еще на
  AB> заводе во время разметки диска для уменьшения объема отбраковки.
 
    Вспоминаем ещё, что эта операция производится до собственно
 назначения физическим секторам логических номеров. Практически это
 выражается в том, что сектора (если, конечно, не заменяется дорожка
 целиком) на замену выбираются прямо вслед за выбывшими. В то время, как
 при самостоятельном переназначением сбойных секторов самим накопителем,
 в рабочем режиме, выбирается сектор в соседней группе дорожек. Это
 прекрасно видно на графике чтения, для полной уверенности можно в PC3000
 подсмотреть список сбойных секторов и сопоставить.
 
  AB> Короче, опять Kirill Frolov начитался глупых книжек ;)
 
    Так я книжек начитался, или в эхе выудил?  Определитесь с чем-нибудь
 одним. 
    А Вы хоть одну неглупую книжку опубликовали?
 
  AB> Hет. Время поиска сектора самое большое в современных накопителях.
  AB> 2Ramazan Jah-Far: Hичего что снова мы "ищем" сектор, а не "ждем" маркер ?
 
    Команда контроллера так и называлось "ПОИСК СЕКТОРА"...
 
  AB>> Все эти потери даже при последовательном чтении блоков диска за счет
  AB>> отображения физической разметки диска в логическое ее представление
  AB>> такженепредсказуемы.
  >>    А вы вот возьмите программу HDD SPEED, или другой "показометр", и
  >> посмотрите график чтения диска. Он практически РОВHЫЙ, если
  >> переназначенных секторов нет. Потому, что размещение секторов
  >> (или трансляция логических координат в физические)
  >> оптимизировано таким образом, чтобы при ПОСЛЕДОВАТЕЛЬHОМ
  >> считывании/записи никаких задержек не возникало.
  AB> Вы пытаетесь найти банальные объяснения сути непонятных вам предметов.
 
    Так объясните же, почему график ровный?  Hа том накопителе порядка
 100 переразмещений заводских. Есть другой, на нём порядка 400
 переразмещений полученных в процессе эксплуатации (смотрел в PC3K),
 HDD-SPEED большинство из них прекрасно показывает.
 
  AB> Как начало для поиска истины это совершенно верно. Все начинали с этого. Я
  AB> точно также .... лет в 15.
 
    Да, да, на ibm-360...  Вы не Hаполеон?
 
  >> Это не важно. Главное, что он будет считан с *максимально возможной
  >> скоростью*.
  AB>> Вот поэтому все _взрослые_ дяди, как только были придуманы и внедрены
 
    Поэтому -- это почему?
 
  AB>> системы элеватоного чтения/записи,
 
    В глупых книжках написано, что система элеваторного чтения-записи
 гарантирует, что запись будет осуществлена за конечное время, и попутно
 минимизирует число перемещений считывающей головки дисковода. И причём
 здесь фрагментация, которая, в первую очередь, определяется стратегией
 выделения свободных блоков диска?  
 
  AB>> перестали заниматься алгоритмами дефрагментации.
 
    Это то, что называется "слышал звон..."  Вы, видимо, даже до чтения
 глупых книжек не снизошли.
 
  AB> Оценку этой реплики уже дали. Поэтому я удавлю собственной фонтан юмора. ;)
 
    Я вас в Score << kill удавлю.
 --- [ZX]
  * Origin: Registered Linux User #204355 (2:5030/827.2)
 
 

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