https://opennet.ru/openforum/vsluhforumID3/3748.html 1. Качество исполнения, запас прочности и надежность накопителей со SCSI<br>интерфейсом как правило выше, чем у IDE.<br><br>2. Два подключенных к одному каналу контроллера IDE накопителя, не могут<br>одновременно передавать данные по шине.<br><br>3. SCSI показывают значительно лучшую производительность в загруженной<br>многозадачной среде, при обилии разрозненных параллельных запросов за<br>счет более оптимального использования шины передачи данных. (конек IDE -<br>линейное чтение, сильная сторона SCSI - случайный доступ).<br><br>Поясняю: Специфика IDE такова, что запросы могут передаваться по одной<br>шине последовательно (одна труба передачи данных, однопоточный режим).<br>Допустим, если 100 процессов обращаются к данным на диске, запросы в<br>рамках одного канала контроллера будут обрабатываться один за другим, каждый<br>следующий после полного выполнения предыдущего (связка: выдача<br>команды - получение данных).<br><br>При использовании SCSI, допускается перекрытие запросов (организуется<br>очередь команд), ответы при этом будут получены https://opennet.ru/openforum/vsluhforumID3/3748.html#15 Tue, 28 Jun 2005 12:47:36 GMT да, вертится гугль на иде-винтах, только не нужно стравнивать самосборные серваки с Савка и спецально заточеные под это системы хранения. К примеру знаете сколько стоит 146гиговый SАТА-шный диск в Хитачевский сторадж? Не всякая SCSI или FC столько денег просит..<br>В среднем IDE дешевле и всякие конторы типа Hitachi, EMC, NetApp начинают предлягать хранилища не только на сказе или фибре, но и на ата-сата. Но там полки с 14-16 дисками, как правило 1-2 штуки стоят в hot-spare pool - т.е. подключены-раскручены, но операций чтения-записи не выполняют. Контроллеры там конечно не интел, хотя XOR-cpu обычно интелевский, что-то типа i960. В общем всегда нужно исходить из задач и желаемых затрат (минимизация времени disaster recovery очень затратная задача). <br>Если у вас нагрузка на сервак 5-10к юзерей в час и час простоя стоит бизнесу хотя бы 10 килобаксов, то купить хранилище за 50к, которое будет обеспечивать 100% (это конечно если его не расстреливают из автомата, жгут напалмом или просто поливают из ведра, хотя для https://opennet.ru/openforum/vsluhforumID3/3748.html#14 Thu, 11 Nov 2004 07:01:56 GMT &gt;Другой контраргумент: ОС точно не знает где сейчас висит головка, а &gt;электроника диска знает.<br><br>Не совсем так, вот например Novell имеет алгоритм кэширования записи Elevator Seek - один в один оптимизация на уровне ОС. НО !!!!! работает только со СКАЗЯМИ !, т.к. у других ничего о _физическом_ положении головок сказать нельзя. Головки при этом перемещаются ЛИНЕЙНО по ВСЕЙ поверхности диска - что хорошо сказывается на ресурсе. https://opennet.ru/openforum/vsluhforumID3/3748.html#13 Sat, 26 Jun 2004 21:22:40 GMT Если Вы имеете в виду FC-AL, то, поверьте, они ОЩУТИМО уступают SCSI в производительности. Они другим берут...<br> https://opennet.ru/openforum/vsluhforumID3/3748.html#12 Tue, 22 Jun 2004 19:26:45 GMT а почему не расмотреть fibre chanell на серверах?<br>помоему ни в чём не уступают скази да и ещё шина длиннее намного ,например для Oracle RAC(кластер) или microsofтовский кластер это рекомендованое решение!<br> https://opennet.ru/openforum/vsluhforumID3/3748.html#11 Sun, 13 Jun 2004 18:53:08 GMT а google на чем вертится? не на ide ли винтах? вот только контроллеры у них не от интел, ессно :) https://opennet.ru/openforum/vsluhforumID3/3748.html#10 Wed, 02 Jun 2004 16:27:36 GMT uldus:<br>&gt; Зависимость вероятности попадания данных из кэша от объема кэша<br>&gt; и параметров диска не линейная, есть оптимум, который и используют.<br><br>Расскажите, pls, как вычисляется этот оптимум. Лично мне сей алгоритм неведом.<br><br>&gt; Кэшировать то что уже считано и то что может быть будет считано<br>&gt; разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором. <br><br>Вы думаете, что диск лучше знает, что операционка будет читать в будущем? :)<br><br>&gt; Другой контраргумент: ОС точно не знает где сейчас висит головка,<br>&gt; а электроника диска знает.<br><br>У диска есть два параметра, определяющих время выполнения запроса: это начальная задержка T0 и скорость считывания/записи V (т.е. время обработки запроса объёмом N байт = T0 + N/V). Чтобы второе слагаемое стало больше первого, с диском надо общаться порциями в несколько сотен килобайт, что, IMHO, бывает нечасто.<br><br>V - это константа, на ней никакими манипуляциями ничего не выиграешь.<br><br>T0 состоит из двух слагаемых: время на перемещение головки и время на ожидание пр https://opennet.ru/openforum/vsluhforumID3/3748.html#9 Wed, 02 Jun 2004 13:01:38 GMT В системе с одним винчестером на канал разницы в производительности можно не заметить. Я, например, взял i865GBF и повесил по одному диску на PATA-контроллеры и по одному - на SATA. Шустро вышло. ИДЕшники против скаженых винтов технологически слабее, другой уровень MTBF - факт. Но ценовой фактор еще более другой :( Хотя, если наткнуться на задачу 365х24 и высокой ценой простоя, то скаженым накопителям альтернативы нет. В конце концов, идешные винты почти тотально ушли в бытовой сектор, где приоритет отдан себестоимости. Оно хорошо сказалось на цене, но отвратительно на ТТХ. <br><br>Насчет таггед кьюинга - тот еще вопрос. Примерно как с фрагментацией/дефрагментац%C https://opennet.ru/openforum/vsluhforumID3/3748.html#8 Tue, 01 Jun 2004 13:33:11 GMT &gt;Если IDE винт на контроллере один, то по скорости он скизи почти <br>&gt;не уступает. Про цену связки винт+контроллер умолчим :). <br><br>По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что насмену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем.<br><br>имхо вообще не стоит рассматривать IDE в промышленной системе, поскольку нагрузка напорядок выше всяких офисных сервачков юзеров на 50. Вопрос о цене на винчестер 300$, где процессор стоит 1-2k USD (xeon пока дороже нет?) не рассматривается. (умолчим о ppc, spark)<br><br>далее можно было бы сказать о диапазоне рабочих температур, как один из важных факторов отказоустойчивости винчествера, а также о композитных материалах и драг.металлах, но в этом нет смысла, ибо промышленная система это не большой "домашний писюк"...<br><br><br><br> https://opennet.ru/openforum/vsluhforumID3/3748.html#7 Tue, 01 Jun 2004 10:52:22 GMT &gt;Для начала давайте сравним объём кэша в операционке и в диске. <br><br>Зависимость вероятности попадания данных из кэша от объема кэша и параметров диска не линейная, есть оптимум, который и используют. Кэшировать то что уже считано и то что может быть будет считано разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.<br><br>Другой контраргумент: ОС точно не знает где сейчас висит головка, а электроника диска знает.