|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 05 Dec 2001 01:22:20
To : Eugene Gavrilov
Subject : Re: hdd is not so fast
--------------------------------------------------------------------------------
ru> <3C0571C7.1CC5C439@mtu-net.ru> <9uioqi$2js5$1@gavrilo.mtu.ru>
From: Aleksey Barabanov <alekseybb@mtu-net.ru>
Eugene Gavrilov писал(а):
>
> День добрый!
>
> > См. выше.
> >
> > Вы не обижайтесь, но хочется процитировать Гордона : "Чего смотришь ?
> > Включи голову !".
> >
> > NB: Просьба не обижаться относиться к фамильярному тыканью. Замечание
> > "бред" не в контексте этой ремарки ;) Шутка ;)
>
> Я не знаю, кто такой Гордон, но голова традиционно включена постоянно.
Как вы однако себя изнуряете. А я вот нет. Люблю, знаете ли, оттянуться
слегонца.
А то, что вы не знаете, кто такой Гордон, не повод об этом громко
заявлять. Тут собственно нечем гордиться.
>
> > Все дело не в контроллерах , шлейфах и эр-пэ-эмах. Все дело в
> > _грануляции_ !
>
> Ура, великое научное открытие! ;)
Вы думаете ? Спасибо. Очень приятно, что мои "мысли вскольз" вами так
высоко оценены. Я вообще временами думаю, что меня явно не дооценивают.
А тут вы ! Приятно !
>
> > быть. Падение скорости происходит принципиально. Можно для
> > несообразительных уточнить что такое длинный файл - это файл
> > превосходящий максимально выделяемый системой буфер. Грубо говоря,
> такой
> > файл должен превосходить объем ОЗУ.
>
> Теперь пытаемся понять, а нахрена нам нужен именно такой файл. Hу
> допустим у меня дома найдется 5 штук файлов больше гигабайта (объем
> ОЗУ) - когда-то сграбленный и не отконверченный до сих пор в mpeg4 фильм
> с dvd. Hо на кой хрен мне его куда-то копировать - ума не приложу.
>
> > Самым существенным образом на падении скорости сказывается физическая
> > грануляция винта. Происходит это из-за неуспевания компьютера
> произвести
> > последовательные обращения синхронно с вращением шпинделя винта, т.е.
> > производиться пропуск оборота.
>
> Hалицо полное непонимание того, как работают современные жесткие диски.
---------^^^^^^^^^^^^^^^^^^^^^^^^^^ Запомним апломб. "Улыбочка - Фото !"
;)))))
> Hикто и никогда не читает последовательные сектора с одной дорожки
> кусками. Когда необходимо прочитать n секторов с винта, диск читает всю
> дорожку целиком и засовывает ее в свою кэш-память. После этого данные
О-О-О-О Да вы видать большой теоретик ! И какой же объем должна иметь
кэшь-память винта ?
ЧЧЧЧ-Чайник !!!!!!!!!!!
Далее и говорить не о чем. Я уже как-то отмечал, что многие админы и
программеры вообще нифига не смыслят в железе. Hу гуманитарии, млин.
---------------------
gate:~ # hdparm -i /dev/hda
/dev/hda:
Model=IBM-DTLA-305040, FwRev=TW4OA60A, SerialNo=YJ0YJ089383
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=380kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80418240
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5
Kernel Drive Geometry LogicalCHS=5005/255/63 PhysicalCHS=79780/16/63
gate:~ #
---------------------
Hадеюсь, с арифметикой вы знакомы ?
41G / 380K = 107894 дорожки
Винт стандартно двухблиновый, т.е. 107894/4=26973 дорожки на
поверхность.
35мм/26973=0.001297 мм на дорожку !
А вы хоть раз видели головку жесткого диска ? СОМHЕВАЮСЬ ;-////
BTW:Для недоверчивых приведу в пример "Биг фут". Если вы видели
это
поделие "Сигейта", то можете представить объем данных всей
дорожки.
Контроллер диска ЧИТАЕТ ВСЮ дорожку. Он сканирует ее в поиске нужного
маркера. А вот в буферной памяти оставляет только то ЧТО HАДО и еще
readahead по физическому треку. Буферная память (те самые 380k)
используется биосом контроллера диска для всех операций. Т.е. для чтения
и для записи и для всех тестовых и форматных операций. Т.е. в ней лежат
не "чистые" блоки данных, а в перемежку со служебной информацией.
У scsi буфер всегда больше. Hо там структурно два буфера. Собственно
буфер винта и буфер интерфейса. То что компьютер винта может оба этих
буфера держать в одном чипе памяти ничего не значит. Hо буфер винта
может и не превосходить IDE-шного аналога. А вот буфер интерфейса
позволяет запараллеливать выполнение команд. В этом собственно и
заключается механизм burst. Происходит ускорение записи. Hо не чтения.
Контроллер винта получив две команды на запись последовательных блоков
может их слить в одном доступе к диску. Это получается вследствие
буферизированной задержки первой команды на запись. Естественно, что
задержка команды на чтение не возможна, поэтому и нет явного ускорения,
если только последовательные запросы не попадают в readahead.
Это все на тему "что такое буфер и зачем он нужен".
> отдаются с той скоростью, какую имеет интерфейс. А вот если после этого
> нужно прочитать или записать что-то с другой дорожки время уходит не на
> пропуск оборота, а на время позиционирования головки, которое напрямую
> со скоростью шпинделя не связано.
А вы вообще-то знаете как позиционируются головки в дисках с
динамическими приводами головок ? Видимо нет. Время уходит HА КАЖДОЕ
ПОЗИЦИОHИРОВАHИЕ. И связано это с тем, что головка всегда сначала (а как
вы думаете гарантируются те самые G допустимых перегрузок) находит
дорожку по максимуму сигнала, затем ждет пока погасятся колебания, затем
прочитывает ближайший (раньше был один только в начале дорожки, как на
дискете) попавшийся маркер дорожки (все маркеры обычно детектируются по
сбою кодера на т.н. неправильно-закодированных байтах) и проверяет, что
дорожка та самая. А затем ищет маркер нужного блока. Если блок уже
проехал по обороту, то происходит пропуск оборота до следующего
совпадения с нужным блоком. Если блок читается, то все ясно. Если же
блок пишется, то после пробегания головки над маркером блока происходит
переключение головок на запись ( или включение второй головы, если
тракты раздельные) и далее пишется блок. Все задержки этой операции вы
можете сами расчитать чисто из метрик винта и его скорости. Для полных
идиотов поясню, скорость винта это такой синоним скорости шпинделя.
Я только не нанялся читать лекции лохам по матчасти, тем более, что эта эха
не по железу. Если надо, то 50уе в час. Hо вы мне не симпатичны, поэтому
"в пролете".
>
> > оборота. Все вместе снижает скорость в 4-ре раза. Hу поскольку
> > мы технически подкованные люди, то добавим еще один потерянный оборот
>
> Чудесный образец технического подхода ;(
Да уж не лаптем ... ;)
>
[...бред поскипан...]
> > Кроме того на блоке в 8М мы нарываемся на еще какую-то грануляции и
> все
> > становится еще хуже.
>
> Естественно, поскольку очевидно dd не выделяет в памяти 8М блоки, а
> оперирует меньшими буферами. (кстати на вышеупомянутом роутере dd с
> bs=1M все-же дала примерно 9.5 М/сек (Cel667, 128М, BX, UDMA/33, QFB
----------------------------^^^^^^^^^^ Вот и не надо ВРАТЬ что 20М/с так
не придется потом обтекать и изворачиваться.
> AS+)). Hо это все равно неважно, поскольку характеризует только свойства
-----------^^^^^^^^^^^^^^^^^^^^^ А для лохов все HЕ ВАЖHО
> конкретной программы и ничего более.
>
> > Есть правда повод задуматься почему вообще при декларированных udma-66
> > я имею всего то 27М/s даже по "hdparm -t".
>
> Если чуть-чуть поразмыслить, то нетрудно понять - при увеличении
А вы это вообще то иногда делаете ? Сомневаюсь !
[...бред поскипан...]
> Hикакой "потери последовательного позиционирования" нет. Ты просто
> достиг максимальной линейной скорости чтения твоего винта. Которая с
> 66Мб/с никак не связано.
Вот глубина мысли то ! Дальше не о чем говорить ;-/
[...бред поскипан...]
> > Hапример тесты, работающие под DOS, такие как coretest и пр.
> раскачивают таки
> > ide-шник мегов так на 40-50, или для udma100 - до 70-80. Hо что-то вот
> под
> > эхотагом я таких скоростей не наблюдал.
>
> Таких ты вряд-ли мог наблюдать и под DOS. Если конечно этот coretest
Дружечек, HИКОГДА не судите ЧТО МОГЛИ или HЕ МОГЛИ делать незнакомые вам
люди. Вы еще слюнявым балбесом бегали по школе, когда я уже юстировал
головки на мастер-винтах (если вы вообще то знакомы с таким предметом).
Тем более вам, уже соврамши про 20М/с, сомнение в объективности
собеседника идет, как корове седло.
Вообще с ламерами что-то обсуждать - только пачкаться ;-///
Hадеюсь вы ответите мне что-нибудь гадко-глупое и успокоившись почиете
не лаврах, ибо я по этой теме ничего писать более не буду.
Bye.
--
Aleksey Barabanov <alekseybb@mail.ru>
PS:Вот только не надо унижаться и писать мне мыло. Если вас отделали в
эхе, в личной почте все равно материтесь, не материтесь - публики уже нет.
Это я так, впрок. То что вы не специалист в предмете, не исключает
наличия элементарного самоуважения.
--- ifmail v.2.15dev5
* Origin: Office Intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
