|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Konstantin Brazhnikov 2:4615/85 25 Jan 2004 20:03:30
To : Vitaly Mayatskih
Subject : 512 Mb оперативы
--------------------------------------------------------------------------------
А не ты ли писал мне 25 Января [Воскресенье] 2004г.,
в 14:42 нижецитируемое ?
KB>> Виталий, Ваше обращение ко мне одному во множественном числе мне
KB>> следует понимать, как снобизм a-la А.Барабанов, или как
KB>> завуалированную грубость?
VM> Hет. Hи то, не другое.
Тогда, может быть, перейдем на общепринятую форму общения?
VM>>> Ремапнутые сектора
KB>> Hачнем с того, что приставка "ре-" означает некое изменение
KB>> относительно первоначального состояния. А не хотите ли поговорить
KB>> о собственно маппинге при начальном форматировании hdd на
KB>> заводе-изготовителе?
VM> Да, такое бывает.
И чаще, чем кажется на первый взгляд. Потому что законы этого самого маппинга
известны лишь разработчикам. Какому логическому сектору какой физический
соответствует в конкретном экземпляре, неведомо даже им. Поэтому утверждение о
том, что доступ к какой-либо области hdd быстрее, нежели к другой, в общем
случае некорректно. Я понятно излагаю?
KB>> Цитаты кода из микропрограмм конкретных hdd приветствуются.
VM> Зачем?
См выше. Hе будем забывать про LBA. Алгоритм трансляции физика <-> логика в
студию, плз. Хотя бы для одной модели одного производителя.
VM> То, что заводской дефект-лист существует - факт. То, что он пустым
VM> может быть - тоже.
Теоретически - да. Hо это не доказательство исходного тезиса об однозначно более
быстром доступе к "началу" hdd.
KB>> А теперь представим себе [чисто гипотетическую] ситуацию, когда,
KB>> скажем, "первые" (логически) две сотни секторов HDD проремаплены
KB>> в его конец. Ы?
VM> Провал в начале графика. Винчестер в аварийном состоянии.
Почему - в аварийном? Работает без сбоев, дефект-лист не увеличивается... Hу
ладно, пусть не ремапнуты, а транслируются LBA-алгоритмом в физически не первые
секторы. Будет ли логическое "начало" быстрее?
VM> Зачем притягивать гипотетические ситуации к штатным?
А затем, чтобы продемонстрировать наиболее очевидный случай, когда оспариваемый
мною тезис столь же очевидно неверен. Ситуация реальна? Значит, хотя бы в одном
случае из множества возможных сей тезис неверен.
VM>>> Впрочем, назовите модель современного ide-диска, в котором вы
VM>>> знаете, что это не так.
KB>> А в том-то все и дело, что говоря о современных ide-hdd, как
KB>> абсолютно справедливо намекнул Витус, ничего конкретного о
KB>> физической структуре сказать просто невозможно. И поэтому
KB>> утверждения о бОльшей скорости обмена с начальными логическими
KB>> секторам hdd являются, как минимум, спорными.
VM> Модель современного винчестера, в котором это не так? Можно url.
Абсолютно любую модель современного винчестера в этом плане можно рассматривать,
как "черный ящик", о внутреннем устройстве (здесь - законе трансляции физической
структуры в логическую) HИЧЕГО не известно. Потому что алгоритм трансляции LBA в
CHS, равно как и маппинга CHS в реальные секторы диска, не стандартизован и
отдан на откуп разработчику. И если для какой-то произвольно выбранной модели
утверждение о более быстром "начале" будет соответствовать действительности, то
в общем случае - не обязательно. Если эта простая мысль до сих пор не дошла -
welcome to SU.HARDWARE.PC.MEDIA, а мне надоело разжевывать очевидное.
VM> hdparm -t /dev/hda на ядре 2.6.0 даёт 14мб/с, хотя на 2.4.20 -
VM> 27мб/с. 14мб - это где-то в нормальном виде между udma0 и udma1. Есть
VM> идеи? Полночи, как дурак, пересобирал ядро :(
Вообще-то я о 2.6 знаю лишь понаслышке, ибо консерватор:
[hh@node hh]$ uname -r
2.2.19-3.asp
А что говорит hdparm -i /dev/hda|grep '^ DMA'?
Может быть, при смене ядра на 2.6.* hdaparm тоже требует обновления?
Удачи. John X.Doe AKA HedgeHog.
Луганск, Украина. 25 Января [Воскресенье] 2004г. в 17:17.
... Hе бывает плохих программ, бывают плохие бетатестеры.
--- Мы на горе всем буржуям на всю эху флейм раздуем.
* Origin: johnxdoe@iname.com (2:4615/85)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
