1. Качество исполнения, запас прочности и надежность накопителей со SCSI
интерфейсом как правило выше, чем у IDE.2. Два подключенных к одному каналу контроллера IDE накопителя, не могут
одновременно передавать данные по шине.3. SCSI показывают значительно лучшую производительность в загруженной
многозадачной среде, при обилии разрозненных параллельных запросов за
счет более оптимального использования шины передачи данных. (конек IDE -
линейное чтение, сильная сторона SCSI - случайный доступ).Поясняю: Специфика IDE такова, что запросы могут передаваться по одной
шине последовательно (одна труба передачи данных, однопоточный режим).
Допустим, если 100 процессов обращаются к данным на диске, запросы в
рамках одного канала контроллера будут обрабатываться один за другим, каждый
следующий после полного выполнения предыдущего (связка: выдача
команды - получение данных).При использовании SCSI, допускается перекрытие запросов (организуется
очередь команд), ответы при этом будут получены распараллеленно
(асинхронная передача), при этом устройство
заведомо зная подробности по командам находящимся в очереди, производит
оптимизацию самостоятельно - минимизируя движение головок.
URL:
Обсуждается: http://www.opennet.me/tips/info/686.shtml
полностью согласен, но почему не говорите о минусах SCSI? цена например =)
а почему не говорят о альтернативе SATA ??
> Два подключенных к одному каналу контроллера IDE накопителя,
> не могут одновременно передавать данные по шине.А это никто не может, ибо это невозможно в принципе - каждое устройство занимает шину целиком. К тому же это малоактуально.
> При использовании SCSI, допускается перекрытие запросов
> (организуется очередь команд), ответы при этом будут получены
> распараллеленно (асинхронная передача), при этом устройство
> заведомо зная подробности по командам находящимся в очереди,
> производит оптимизацию самостоятельно - минимизируя движение головок.Эту оптимизацию должна производить операционная система. А на разницу в цене IDE и SCSI я докуплю памяти, где эта оптимизация и будет производиться.
>Эту оптимизацию должна производить операционная система. А на разницу в цене IDE
>и SCSI я докуплю памяти, где эта оптимизация и будет производиться.По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте, который будет дисковые операции планировать и расквантовывать ? :-)
> По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте,
> который будет дисковые операции планировать и расквантовывать ? :-)Для начала давайте сравним объём кэша в операционке и в диске. Т.к. обычно объём оперативки >> кэша на брюхе у диска, то операционка в любом сучае должна оптимизировать свои запросы к диску. А оптимизировать на малой памяти то, что уже было оптимизировано на большой - это то же самое, что паковать плохим архиватором то, что уже упаковано хорошим.
>Для начала давайте сравним объём кэша в операционке и в диске.Зависимость вероятности попадания данных из кэша от объема кэша и параметров диска не линейная, есть оптимум, который и используют. Кэшировать то что уже считано и то что может быть будет считано разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.
Другой контраргумент: ОС точно не знает где сейчас висит головка, а электроника диска знает.
uldus:
> Зависимость вероятности попадания данных из кэша от объема кэша
> и параметров диска не линейная, есть оптимум, который и используют.Расскажите, pls, как вычисляется этот оптимум. Лично мне сей алгоритм неведом.
> Кэшировать то что уже считано и то что может быть будет считано
> разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.Вы думаете, что диск лучше знает, что операционка будет читать в будущем? :)
> Другой контраргумент: ОС точно не знает где сейчас висит головка,
> а электроника диска знает.У диска есть два параметра, определяющих время выполнения запроса: это начальная задержка T0 и скорость считывания/записи V (т.е. время обработки запроса объёмом N байт = T0 + N/V). Чтобы второе слагаемое стало больше первого, с диском надо общаться порциями в несколько сотен килобайт, что, IMHO, бывает нечасто.
V - это константа, на ней никакими манипуляциями ничего не выиграешь.
T0 состоит из двух слагаемых: время на перемещение головки и время на ожидание прихода под головку нужного сектора; причём второе существенно больше первого (паспортное время задержки обычно почти совпадает с полуоборотом диска).
Операционная система видит диск как линейно пронумерованный набор секторов и знает, что чем больше различаются номера секторов, тем дальше надо двигать головку. Поэтому первое слагаемое, составляющее T0, операционная система оптимизирует достаточно хорошо.
При упорядочении обращений к диску по номерам секторов (а хорошая операционка, особенно многозадачная с "умным" планированим процессов именно так и делает) минимизируется и ожидание прихода сектора под головку (для случаев обращения в один цилиндр). Так что диску тут просто нечего упорядочивать.
И наконец, последний гвоздь в крышку гроба:
Если в системе выполняются транзакции (надеюсь, никому не надо объяснять, что это такое), к числу которых относятся файловые системы NTFS (W'NT) и UFS+SoftUpdates (FreeBSD), то очерёдность записи на диск определяется программами и НЕ ДОЛЖНА МЕНЯТЬСЯ ДИСКОМ. Так что диску ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ запись на него; а при достаточной памяти (купленной на разницу в стоимости IDE и SCSI) чтение хорошо кэшируется операционкой в памяти, установленной на мат.плате.
bass:
> По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что на смену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем.О какой скорости мы говорим - о скорости электрического интерфейса или о скорости работы механики диска? Тормозом является именно механика (именно она обеспечивает T0), а она от интерфейса (IDE или SCSI) не зависит.
Конечно, в более догогие SCSI-диски ставят более качественную и быструю механику. Но если взять дорогой IDE-диск, то он будет работать так же, как SCSI, при меньшей чем у SCSI цене. IMHO.
PS: А что у вас делают в промышленных системах процессоры Xeon, которые сами греются ка муфельная печка?
>Другой контраргумент: ОС точно не знает где сейчас висит головка, а >электроника диска знает.Не совсем так, вот например Novell имеет алгоритм кэширования записи Elevator Seek - один в один оптимизация на уровне ОС. НО !!!!! работает только со СКАЗЯМИ !, т.к. у других ничего о _физическом_ положении головок сказать нельзя. Головки при этом перемещаются ЛИНЕЙНО по ВСЕЙ поверхности диска - что хорошо сказывается на ресурсе.
Если IDE винт на контроллере один, то по скорости он скизи почти не уступает. Про цену связки винт+контроллер умолчим :).
>Если IDE винт на контроллере один, то по скорости он скизи почти
>не уступает. Про цену связки винт+контроллер умолчим :).По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что насмену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем.
имхо вообще не стоит рассматривать IDE в промышленной системе, поскольку нагрузка напорядок выше всяких офисных сервачков юзеров на 50. Вопрос о цене на винчестер 300$, где процессор стоит 1-2k USD (xeon пока дороже нет?) не рассматривается. (умолчим о ppc, spark)
далее можно было бы сказать о диапазоне рабочих температур, как один из важных факторов отказоустойчивости винчествера, а также о композитных материалах и драг.металлах, но в этом нет смысла, ибо промышленная система это не большой "домашний писюк"...
В системе с одним винчестером на канал разницы в производительности можно не заметить. Я, например, взял i865GBF и повесил по одному диску на PATA-контроллеры и по одному - на SATA. Шустро вышло. ИДЕшники против скаженых винтов технологически слабее, другой уровень MTBF - факт. Но ценовой фактор еще более другой :( Хотя, если наткнуться на задачу 365х24 и высокой ценой простоя, то скаженым накопителям альтернативы нет. В конце концов, идешные винты почти тотально ушли в бытовой сектор, где приоритет отдан себестоимости. Оно хорошо сказалось на цене, но отвратительно на ТТХ.Насчет таггед кьюинга - тот еще вопрос. Примерно как с фрагментацией/дефрагментац%C
а google на чем вертится? не на ide ли винтах? вот только контроллеры у них не от интел, ессно :)
да, вертится гугль на иде-винтах, только не нужно стравнивать самосборные серваки с Савка и спецально заточеные под это системы хранения. К примеру знаете сколько стоит 146гиговый SАТА-шный диск в Хитачевский сторадж? Не всякая SCSI или FC столько денег просит..
В среднем IDE дешевле и всякие конторы типа Hitachi, EMC, NetApp начинают предлягать хранилища не только на сказе или фибре, но и на ата-сата. Но там полки с 14-16 дисками, как правило 1-2 штуки стоят в hot-spare pool - т.е. подключены-раскручены, но операций чтения-записи не выполняют. Контроллеры там конечно не интел, хотя XOR-cpu обычно интелевский, что-то типа i960. В общем всегда нужно исходить из задач и желаемых затрат (минимизация времени disaster recovery очень затратная задача).
Если у вас нагрузка на сервак 5-10к юзерей в час и час простоя стоит бизнесу хотя бы 10 килобаксов, то купить хранилище за 50к, которое будет обеспечивать 100% (это конечно если его не расстреливают из автомата, жгут напалмом или просто поливают из ведра, хотя для таких случаев делают распределенные резервные ВЦ) сохранность данных без простоев (несколько снижая реакцию во время ребилда массива при выходе диска из строя) очень хорошее решение. Даже 100к в этом случае не заоблачная цена, а бывают довольно небольшие хранилища (до 10Тб) которые стоят по 5-10 мегабаксов...
а почему не расмотреть fibre chanell на серверах?
помоему ни в чём не уступают скази да и ещё шина длиннее намного ,например для Oracle RAC(кластер) или microsofтовский кластер это рекомендованое решение!
Если Вы имеете в виду FC-AL, то, поверьте, они ОЩУТИМО уступают SCSI в производительности. Они другим берут...