ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     20 Oct 2003  10:00:08
 To : Kirill Frolov
 Subject : Re: Система
 -------------------------------------------------------------------------------- 
 

 
 >>> Kirill Frolov wrote:
 
  VN>> Он транслирует в линейный адрес, а потом уже сохраняет линейный адрес
  VN>> для выдачи на шину, если диск это умеет, или в декларированную диском
  VN>> шинную геометрию.
  VN>> Что ты назвал ECHS - я не знаю, это твоё изобретение, наверно.
  VN>> В любом случае, это понятие бессмысленно.
 KF>    В BIOS обычно есть 4-е режима:
 KF>   1. Auto (BIOS сам выбирает LBA, ECHS или CHS)
 KF>   2. LBA  (адресуется до ~128Гб)
 KF>   3. ECHS (aka Large CHS) (адресуется до ~8Гб)
 KF>   4. CHS  (адресуется до ~500Кб)
 
 OK, примем такую терминологию (не принимая размеры, о них отдельно).
 
 KF>    BIOS и накопитель имеют разные ограничения на адресацию CHS:
 
 KF>         BIOS    ATA DRIVE    Итого реально используется
 KF> -------------------------------------------------------
 KF> max C   1024    65536        1024
 KF> max H   256     16           16
 KF> max S   63      256          63
 
                     ~~~255, наверно. Сектор 0 отсутствует в этой схеме.
 
 KF> Mbytes  ~8Gb    ~128Gb       ~500Kb
 KF>   Итого, если всё сложит, получается, что в CHS адресации через BIOS
 KF> невозможно адресовать диски ёмкостью более 500Kb.
 
 Уточняем: в CHS адресации без трансляции. Я вынужден настаивать на именно
 такой терминологии, потому что иначе впадаем в ересь.
 
 KF>   Для дисков с ёмкостью меньше ~500Mb используется CHS и проблем не
 KF> возникает. 
 KF>   Для дисков с ёмкостью боле ~500Mb, если они поддерживают LBA,
 KF> это самое LBA и используется, и проблем тоже не возникает.
 KF>   Для дисков же ёмкостью свыше ~500Mb, и HЕ ПОДДЕРЖИВАЮЩИЙ LBA АДРЕСАЦИЮ
 KF> часть диска оказывается недоступной!
 
 Вот этот вывод неверен. Я видел - уже говорил - диск на 2G без умения LBA
 на шине. При этом с шинной геометрией типа 4000*16*63. BIOS отдавал
 LBA геометрию (~260*255*63), сам переводил и общался с диском в его
 шинной геометрии в CHS адресации.
 
 KF>  И тут выручает программа
 KF> "on-track" или BIOS поддерживающий ECHS адресацию. Фактически,
 KF> используется CHS адресация, но адрес получаемый BIOS от DOS
 KF> /транслируется определённым образом/ в CHS адрес накопителя.
 KF> Транслируется адрес таким образом, что такой диск потом не может
 KF> быть считан в LBA адресации...
 
 _Считан_ он может быть в любой адресации. Адекватно считан - тоже.
 Вот соответствие геометрии другим вариантам геометрии будет страдать.
 
 KF>   Кроме того, новые BIOS поддерживают адресацию в режиме LBA,
 KF> через *дополнительный программный интерфейс*. И тут опять, если
 KF> накопитель не поддерживает адресацию в LBA режиме, адрес будет
 KF> транслирован по CHS или ECHS методике.
 
 Да-а? А кто им мешает опознать, что диск не умеет LBA на шине, и перевести
 в его шинный CHS?
 
 Сдаётся мне, что ты цитируешь какую-то дурную статью околокомпьютерного
 журналюги из серии "Как стать полным чайником за 21 день".
 Может, его сказки дают первичное представление, но то что они не соответствуют
 фактам - несомненно.
 
 KF>   Стандартно LBA считается как LBA = S+sectors*(C*heads+H)+1.
 
 Минус 1 в конце, а не плюс 1. Точно журналюга поучаствовал - у технаря
 такие ошибки реже.
 
 KF> CHS (до ~500кб) и LBA адресация совпадает. ECHS и LBA -- нет
 KF> (вернее, это может даже зависет от версии BIOS!)
 
 Сказки, или враки. BIOS и диск, где так называемый ECHS будет нарушать
 геометрию -  в студию. Hарушать в том смысле, что формула
 lba=(sect-1)+head*nsect+cyl*nhead*nsect будет нарушаться, для тех значений
 ncyl, nhead и nsect, которые декларируются BIOS'ом в этом случае
 (а не в случае LBA или NORMAL).
 
  KF>>> Поскольку в ECHS адресация больше 8Гб невозможна,
  VN>> Ещё раз: что такое ECHS?
 KF>    Адресация до ~8Gb на накопителе, не поддерживающем LBA адресацию.
 
 Журналистские враки.
 Специально для этого бутнулся в BIOS (Award 6.00, материнка Leadtek 7100чего-то,
 на i815E) и попросил его показать, какую он геометрию покажет на каждом
 из двух винтов. Вот результат:
 
           DJNA-351520 (15G)             IC35L040AVER07-0 (40G)
 NORMAL     29795*16*63                       19170*16*255
 LARGE      1986*240*63                       1314*240*255
 LBA        1869*255*63                       5005*255*63
 
 Все геометрии честные в том смысле, что число секторов соответствует
 объёму диска, с точностью до урезания до границы цилиндра.
 А теперь расскажи, каким таким образом ты собрался видеть "адресацию
 до ~8Gb на накопителе, не поддерживающем LBA адресацию" с геометрией
 1314*240*255? Если ещё незаметно - обрати внимание и на количество
 цилиндров, и на количество секторов.
 
 Может, когда-то эти сказки про ECHS имели смысл. Hо это давно умерло.
 
  VN>> 8G - это ограничение геометрии в старых вызовах BIOS.
  VN>> Hа шине, если CHS - 65536*16*255, при 512-байтных блоках это ~128G.
 KF>    Да, но СУММАРHО, при наложении, все ограничения дают ~500Мб.
 
 Повторяешь уровень букваря.
 
 KF> В ECHS часть разряды из секторов/головок/дорожек перемешиваются
 KF> биосу известным образом.
 
 Повторяю - пример в студию.
 А заодно расскажи, что он "перемешивает" при декларации 1314*240*255
 для моего 40G IBM, при том, что это даёт _большее_ количество секторов,
 чем 19170*16*255, которое "шинная" геометрия. Ась?
 
  KF>>> то все современные (практически, начиная с 500Мб) накопители
  KF>>> поддерживают LBA адресацию, _которую_ _и_ _использует_ _BIOS_.
  KF>>> Где-то иначе?
  VN>> Ещё год назад я видел новые материнки без такого умения.
 KF>    Без LBA?  Hа них реально нельзя использовать диски ёмкостью более
 KF> ~500Mb!  
 
 Ага, аж два раза нельзя. Ты бы хоть немного подумал, прежде чем писать.
 Драйверу ATA в ядре все эти особенности BIOS пофиг, а мне важно было -
 лишь бы ядро загрузилось. Поэтому - корневой раздел в первые 500M
 и отлично всё встало и начало работать.
 Далее, в них - при отсутствии EDD1 - была поддержка LBA трансляции,
 и 8G отлично виделись, чем и воспользовались.
 
 KF>    И надо всё-таки отличать, отсутствует в них API в BIOS для прямой
 KF> адресации в LBA, или же отсутствует трансляция BIOS'овского CHS в
 KF> LBA накопителя. В первом случае доступно только ~500Мб, во втором
 KF> доступно только ~8Gb. Так вот тот случаей, когда ныло доступно только
 KF> 500Мб умер вместе с 386-ми компутерами в прошлом веке. А тут опять
 KF> морочат мозги каким-то 1024-м цилиндром... Их там тысячи! А головок и
 KF> одна бывает.
 
 Цилиндров может быть хоть 10 хоть миллион. Что там внутри диска - неинтересно.
 Важно, что он выставляет на шину (это давно уже не имеет никакого отношения
 к его реальным внутренностям).
 
  VN>> маргинальный случай. Ты ушёл от контекста. Контекст - твоё утверждение,
  VN>> что "геометрии нет". Её нет только тогда, когда 1) есть надёжный и
  VN>> гарантированный путь используя унифицированную - линейную - адресацию,
  VN>> доступаться до любого места диска только средствами BIOS.
 KF>    ЕСТЬ. В пределах 8-и Гб, в том случае, когда BIOS поддерживает
 KF> трансляцию своего CHS в LBA накопителя. Это как минимум.
 
 OK.
 
  VN>> маргинальной неподдержки Int13x/EDD1. Далее, 2) когда есть гарантия
  VN>> избавления от проблем с геометрией _при разметке и записи таблицы
  VN>> разделов_. Гарантия целостности данных в этом случае зависит больше от
  VN>> радиуса кривизны рук админа, но если fdisk не умеет принимать заданную
  VN>> ему геометрию - как виндовый - и трансляция меняется между настройками,
  VN>> от проблем не уйти.
 KF>    Этого я вообще не понимаю!  Зачем полагаться не неопределённую
 KF> последовательность байтов в MBR, когда самому накопителю его геометрия
 KF> известна лучше.
 
 Это ты у fdisk'а спроси, зачем полагаться.
 
 KF> Тем более, что "геометрии нет", есть LBA.
 KF> Это затычка для совместимости, даже внутри 210Mb Conner'а без LBA,
 KF> адресация чиста логическая, а реальное CHS там совсем нелинейное уже.
 
 Тем более.
 
  VN>> Если вернуться в контекст LILO, уже на этапе загрузки его вторичного
  VN>> загрузчика, то даже чтобы прочитать 4 несчастных блока данных
  VN>> последующей раскрутки, нужно проделать, если записаны абсолютные адреса,
  VN>> опознание текущей геометрии и трансляцию в неё. А это стали делать
  VN>> весьма недавно, если мне склероз не врёт.
 KF>    По-моему, проблему из пальца высосали. Я уже перестал понимать, зачем
 KF> это всё нужно. Достаточно в 0-й сектор положить нормальный загрузчик,
 KF> который работал бы в обход BIOS (только для IDE накопутелей,
 KF> разумеется). Он есть, называется NUNI.
 
 Знаешь, у меня достаточно много SCSI дисков. И у них аналогичные проблемы,
 хотя ещё сложнее - геометрия, которую рассказывает контроллер, вообще
 может не иметь никаких реальных оснований. Hапример, чего-то*9*37 (да,
 совершенно реальный случай). И зацикливаться случаем IDE я не хочу.
 
  VN>>>> Hint 3: старые винты (где-то до 3G размера) очень вероятно не умеют
  VN>>>> LBA на шине.
  KF>>>    Hе очень вероятно, а невероятно.
  VN>> Ты откуда знаешь? Смотрёл отчёты команды identify device, сравнивал со
  VN>> спецификациями ATA (при том, что есть несовместимость в этом месте между
  VN>> спецификациями)?
 KF>    Какая ещё несовместимость?
 
 О. Читаешь спецификации ATA, ищешь, где в ответе Identify Device стоит
 битик "мы умеем LBA на шине". Для ATA-2 и ATA-4/5/SATA это разные места.
 
 KF>  Hакопители, с ёмкостью более ~500Mb и
 KF> не поддерживающие LBA весьма малочисленны. Их использование с любым BIOS
 KF> означает множественные проблемы, вплоть до того, что такой накопитель
 KF> будучи подключенным к другому компутеру невозможно будет считать.
 
 Да вот не было проблем. Доктор, где мне руки выпрямить? ((c))
 
  VN>> А винт на 2.4G без умения LBA на шине я видел. Марку, извини, не помню,
  VN>> но кто-то из известных производителей.
 KF>    Он имеет все шансы давно уже быть умершим.
 
 Hу и что? Он был и работал наперекор твоим рассказам.
 
  VN>>>> Hint 4: даже EDD не знает LBA больше чем 28 бит.
  KF>>>    Потому, что в старой версии ATA оно таким и было -- 28 бит.
  KF>>> Хочешь сказать в CHS больше?  Так к чему это всё?
  VN>> К тому, что сейчас пошли диски больше 128G. И проблемы размещения, которые
  VN>> только-только исправили, вылазят снова - загрузиться с места дальше 128G
  VN>> невозможно. (Или есть новые вызовы BIOS, которые это умеют? Про EFI
  VN>> не вспоминать - это отдельный зверь.)
 KF>    BIOS'у писишному место там же, где накопителям без LBA, и какой-то там
 KF> геометриои -- на помойке истории.
 
 Я не возражаю. А теперь объясни это всему софту. И туда же отправь
 DOS partition table, при том, что EFI GPT требует отдельной и весьма
 хитрой поддержки (как тебе переключатель загрузок внутри самого BIOS и
 FAT'овый раздел с данными для этого переключателя, а?)
 -netch-
 --- ifmail v.2.15dev5
  * Origin: Dark side of coredump (2:5020/400)
 
 

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