Сравнение IDE и SCSI с объяснением причин высокой стоимости SCSI дисков, и почему платить за них часто оправдано.URL: http://freesource.info/wiki/Zachem_Nam_SCSI
Новость: https://www.opennet.ru/opennews/art.shtml?num=4634
Статья содержит ряд фатальных глупостей.Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум. А оптимизация записи диском при использовании транзакций вообще недопутима (хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD модифицируются транзакционно.
> Вывод 1: SCSI полезно и на серверах, и на рабочих станциях.Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее.
> Вывод 2: линейная скорость чтения далеко не самое важноеВ прайсах указывают спорость вращения диска, а не линейную скорость чтения. Так что имеющий глаза этот второй вывод уже сделал.
>Статья содержит ряд фатальных глупостей.Не мешало бы добавить, что это IMHO Дмитрия Ю. Карпова, который, как и все смертные, может ошибаться (просто сам об этом забыл, наверное)
>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум
Продолжая это рассуждение, приходим к выводу, что софтверный RAID предпочтительнее "железного". Без коментариев...
>Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее.
К сожалению, в статье ни чего не сказано о том, что Tagged Queue на порядки увеличивает срок службы диска за счет значительно меньших и более "плавных" перемещений головок (механика - самое слабое место любых дисков).
Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE диски раз в пару месяцев. На прокси сервере под Squid для 250 активных юзеров IDE диски рассыпаются моментально.
Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный. В большинстве случаев надежность важнее!
>>Статья содержит ряд фатальных глупостей.
>
>Не мешало бы добавить, что это IMHO Дмитрия Ю. Карпова, который, как
>и все смертные, может ошибаться (просто сам об этом забыл, наверное)
>
>
>>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум
>
>Продолжая это рассуждение, приходим к выводу, что софтверный RAID предпочтительнее "железного". Без
>коментариев...
>
>>Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее.
>
>К сожалению, в статье ни чего не сказано о том, что Tagged
>Queue на порядки увеличивает срок службы диска за счет значительно меньших
>и более "плавных" перемещений головок (механика - самое слабое место любых
>дисков).
>
>Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE
>диски раз в пару месяцев. На прокси сервере под Squid для
>250 активных юзеров IDE диски рассыпаются моментально.
>
>Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный.
>В большинстве случаев надежность важнее!
У sata есть tcq/ncq и вообще можно в зеркало поставить, что будет надежней, чем один сказюк.
а что, на IDE-винчестеры гарантия 1 месяц? 8-I
>а что, на IDE-винчестеры гарантия 1 месяц? 8-I
А время простоя и нервы потраченные на кусание локтей пока рэйд в degraded mode и ищется новый винт на замену ибо сдох hot spare из 10ки и не в первый раз тоже по гарантии меняются, а время простоя компенсируется? ;)
в случае с IDE пара запасных дисков покупается про запас.
>Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE
>диски раз в пару месяцев. На прокси сервере под Squid для
>250 активных юзеров IDE диски рассыпаются моментально.
>
>Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный.
>В большинстве случаев надежность важнее!Простите, а на сколько "мгновенно"? У меня ~300 пользователей и IDE под Squid работает уже 3 года... Когда ждать краха?
не скажу про все диски .. но вот Макстор из глючной партии развалился через год =8-)))
>Оптимизация обращений при чтении д.б. выполнена операционкой, да так,А разве операционки не оперируют с логическим IDE диском который для нее выглядит линейно (LBA) ? Операционка не может точно знать сколько рабочих поверхностей внутри диска, куда перемещены сбойные области и прочие тонкости позиционирования головок.
>А оптимизация записи диском при использовании транзакций вообще недопутима
>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD
>модифицируются транзакционно.Для любых журналов транзакций (БД, файловых систем и т.п.) важно, чтобы данные этих журналов РЕАЛЬНО были записаны на диск. Поэтому очень рекомендуется отключать кэширование записи. А как выполняется сама запись (оптимизировано или нет) не важно.
>>А оптимизация записи диском при использовании транзакций вообще недопутима
>>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD
>>модифицируются транзакционно.
>
>Для любых журналов транзакций (БД, файловых систем и т.п.) важно, чтобы данные
>этих журналов РЕАЛЬНО были записаны на диск. Поэтому очень рекомендуется отключать
>кэширование записи. А как выполняется сама запись (оптимизировано или нет) не
>важно.если мы говорим о external hardware raid, то там должен стоять аккумулятор, которого должно быть достаточно ровно для того, чтобы держать кэш до тех пор пока не будут устранены проблемы (например A1000 от Sun, помнит содержимое кэша 72 часа)
вообще, батарейки на кэше контроллера вещь довольно сомнительная. если быть последовательным, нужно также сохранять кеш HDD или отключать кеширование на запись (производительность), а еще лучше делать как SUN в своих T3 массивах - аккумулятор держит весь девайс в апе, эдакий внутренний UPS. А пока держит, рекомендуется зайти в него с консоли и сделать шатдаун.
согласен, но тогда, в некотором смысле, ситуация тупиковая - оптимизировать движение головок может только контроллер самого диска, а в случае проблем с механикой "отключить" его на время ремонта/замены механики, "попросив не забывать" кэш, невозможно.
Поясните кто знает следующее. Есть сервер HP со встроенным SCSI RAID-контроллером. Управлять кэшированием можно только на логическом томе (например, RAID1), для чего используется память контроллера (32M). Нигде не смог найти, как отключить/включить кэш самих HDD. Как выяснить, работает он, например, на запись или нет?
Возможно, управление кэшированием в таком случае иерархическое: от логического тома до отдельных дисков. Например при "отложенной записи" на логическое устройство запись производится в кэш контроллера и контроллер сразу сообщает хосту об успешно завершенной операции. Далее уже в фоне происходит запись на диски, возможно тоже в режиме "write back", но не обязательно. При "сквозной записи" контроллер не вернет ОК до тех пор, пока данные физически не запишутся на носитель. В свою очередь сам контроллер ожидает подтверждение успешно выполненной операции от каждого диска в массиве, причем и диски работают в режиме "сквозной записи".Возможны варианты:
том wb: контроллер - wb, диски - wb
том wb: контроллер - wt, диски - wb
том wb: контроллер - wb, диски - wt
том wt: контроллер - wt, диски - wb
том wt: контроллер - wt, диски - wtпервый вариант самый быстрый, последний - самый надежный.
конкретная реализация схемы зависит от контроллера.
>Поясните кто знает следующее. Есть сервер HP со встроенным SCSI RAID-контроллером. Управлять
>кэшированием можно только на логическом томе (например, RAID1), для чего используется
>память контроллера (32M). Нигде не смог найти, как отключить/включить кэш самих
>HDD. Как выяснить, работает он, например, на запись или нет?
поправка:
том wb: контроллер - wb, диски - wb
том wb: контроллер - wb, диски - wt
том wt: контроллер - wt, диски - wb
том wt: контроллер - wt, диски - wtИ кстати, даже если том в режиме wb кеширования, можно заставить некоторые операции производить в режиме wt, для этого есть специальные команды и/или флаги. Например для записи метаданных ядром.
вот еще по теме режимов кэширования:
http://www-307.ibm.com/pc/support/site.wss/document.do?lndoc...
>Статья содержит ряд фатальных глупостей.
>
>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском
>давала минимум. А оптимизация записи диском при использовании транзакций вообще недопутима
>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD
>модифицируются транзакционно.
>
>
>> Вывод 1: SCSI полезно и на серверах, и на рабочих станциях.
>
>Естественно, полезно. Если только мы не думаем о том, что деньгами можно
>распорядиться умнее.
>
>
>> Вывод 2: линейная скорость чтения далеко не самое важное
>
>В прайсах указывают спорость вращения диска, а не линейную скорость чтения. Так
>что имеющий глаза этот второй вывод уже сделал.
Ваши высказывания содержат ряд фатальных глупостей, как выраженных здесь, по поводу SCSI дисков, так и по почтовым делам, ваш юношеский задор просто раздражает, глубина вашего незнания просто поражает воображение, а безапеляционные высказывания претендующие на истину в последней инстанции просто бесят. Вам бы лучше Windows пользоваться.
А насчёт дисков SCSI скажу, если действительно требуется высокая производительность с минимальными нагрузками на систему, в том числе и на проц, то лучше SCSI ничего нет.
"разбор" - это конечно очень сильно сказано :) автор просто гений пера и выражения мысли..а то, что колбаса из мяса лучше, чем соевая.. дык г*&^$% вопрос! никто и не собирается спорить :) конечно лучше.
// wbr
>
>"разбор" - это конечно очень сильно сказано :) автор просто гений пера
>и выражения мысли..
>
>а то, что колбаса из мяса лучше, чем соевая.. дык г*&^$% вопрос!
>никто и не собирается спорить :) конечно лучше.
>
>// wbr
Вегетарьянцы с тобой будут спорить :)
>Вегетарьянцы с тобой будут спорить :)Говорят что "вегетарианец" в переводе с санскрита означает "плохой охотник" :)
1. опять сравниваем апельсины vs. яблоки! тем более сравнивать один IDE диск с массивом SCSI да еще с аппаратным RAID где поиск распределен на все диски в массиве, а контроллер сам настолько умен чтобы делать elevator seek. Да и еще на уровне ОС есть всякие оптимизации (/sys/kern/subr_disk.c - bioq_disksort)2. быстрое рассыпание IDE диска под сквидой и 250 юзерями - имхо полный бред, если железка не левая и не была уже до этого убита кривыми руками.
3. tagged queue поддерживали некоторые IDE диски от IBM (кажется серия DTLA).
4. насчет software vs. hardware raid - софтверный действительно иногда быстрее, смотрим сюда: http://www.shub-internet.org/brad/FreeBSD/vinum.html
4c0x:П.2 А не рубите ли вы сплеча... ide диски(механика) в большинстве своем не расчитаны(производитель не заявляет об этом) на безостановочную работу круглые сутки семь дней в неделю и т.д. А далее... 250 юзеров на проксе... :) условия то разные... например с каналом в 128кб :)))) вообоще мало что загнется.
причем тут сутки,неделя и тд. есть стандартные вещи для оценки бесперебойной работы железки: MTBF порядка 500-700 килочасов у современных винтов, собранных не в венгрии или болгарии.а насчет сквида, частых перемещений головок диска и "..Tagged
Queue на порядки увеличивает срок службы.." приведу следующие доводы:1. умейте настроить сквид так чтобы винты жили дольше (хинт: оно любит много RAM)
2. в случае с bsd/linux существует оптимизация перемещения головок на уровне ОС, и не забывайте про системный кэш и ufs_dirhash/softupdates во фре.
>причем тут сутки,неделя и тд. есть стандартные вещи для оценки бесперебойной работы
>железки: MTBF порядка 500-700 килочасов у современных винтов, собранных не в
>венгрии или болгарии.таки есть MTBF а есть режим работы. это две разные вещи.
>2. в случае с bsd/linux существует оптимизация перемещения головок на уровне ОС,
>и не забывайте про системный кэш и ufs_dirhash/softupdates во фре.в вот тут можно чуть подробнее?
// wbr
>в вот тут можно чуть подробнее?подробнее тут: http://fxr.watson.org/fxr/source/kern
>>в вот тут можно чуть подробнее?
>
>подробнее тут: http://fxr.watson.org/fxr/source/kernочень содержательный ответ, большое вам за него человеческое спасибо :)
а можно все то-же, но в более человеческих терминах? например, ссылка в пределах www.t13.org была бы заметно полезнее.
anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними связь?
хотя я и не использую FreeBSD, но все-таки отношусь с большим уважением к FreeBSD Team, равно как и верю в их разум и вменяемость. и хоть убейте но не поверю, что *это* (даже если оно и существует) сделано в указанной части дерева исходников ядра.
// wbr
>anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для
>FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними
>связь?
>>anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для
>>FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними
>>связь?
>
>http://fxr.watson.org/fxr/source/kern/subr_disk.c#L127если я правильно понимаю ситуацию, это аналог/переработка disksort() из оригинальной BSD:
---cut---
Sorting of Disk I/O RequestsThe kernel provides a generic disksort() routine that can be used by all the disk device drivers to sort I/O requests into a drive's request queue using an elevator sorting algorithm. This algorithm sorts requests in a cyclic, ascending, cylinder order, so that requests can be serviced with a minimal number of one-way scans over the drive. This ordering was originally designed to support the normal readahead requested by the filesystem as well as to counteract the filesystem's random placement of data on a drive. With the improved placement algorithms in the current filesystem, the effect of the disksort() routine is less noticeable; disksort() produces the largest effect when there are multiple simultaneous users of a drive.
disksort(dq, bp)
drive queue *dq;
buffer *bp;
{
if (drive queue is empty) {
place the buffer at the front of the drive queue;
return;
}
if (request lies before the first active request) {
locate the beginning of the second request list;
sort bp into the second request list;
} else
sort bp into the current request list;
}
---cut---(c) "Design and Implementation of the BSD 4.4 Operating System"
вопрос собссно - вы уверены, что это все еще имеет практический смысл с точки зрения оптимизации движения головок на современном ATA диске ? :)
// wbr
>вопрос собссно - вы уверены, что это все еще имеет практический смысл
>с точки зрения оптимизации движения головок на современном ATA диске ?
>:)
>
>// wbrУверен. И не только АТА: http://fxr.watson.org/fxr/source/cam/scsi/scsi_da.c#L576
Размер аппаратной очереди команд имхо сильно ограничен по сравнению с bioq. Так что думаю, это имеет смысл даже там, где используется умное железо с tcq и smart seek. Ну например вот этот девайс: http://www.promise.com/marketing/datasheet/file/STSX6000DS_4...
(http://fxr.watson.org/fxr/source/dev/pst/pst-raid.c#L204)И не только *BSD и линукс. Например Novell NetWare.
>3. tagged queue поддерживали некоторые IDE диски от IBM (кажется серия
>DTLA).
>Диски семейства Vancoover 2 поддерживают TCQ.
Их и надо сравнивать со SCSI.
ага на фрии бсд он мож и быстрее ))))
Может я ошибаюсь,но imho MTBF это не время бесперебойной работы...
А время наработки на отказ при соблюдении условий эксплуатиции устройства.
> Может я ошибаюсь,но imho MTBF это не время бесперебойной работы...
>А время наработки на отказ при соблюдении условий эксплуатиции устройства.Ошибаетесь, это СРЕДНЕЕ время наработки на отказ.
Вычисляется по неким статистическим формулам, никто реально не ждет столько времени для проверки этого значения.Еще есть такие параметры, как количество запусков/остановок, число считанных/записанных бит до появления неустранимой ошибки.
Например у Hitachi Deskstar 180GXP параметры такие:
количество запусков/остановок: 40.000,
число считанных/записанных бит до появления неустранимой ошибки: 1*10E14.Кстати, гарантия на этот HDD у них 1 год, а у SCSI-винчестеров - 5 лет. Кстати, раньше(2002 год) на IDE-винчестеры было 3 года гарантии.
Везде нужно правильно выбирать. Если вместо покупки SCSI дисков нужного объёма Вы можете купить IDE и Гиг оперативки, и этого Гига хватит для минимизации обращений к диску (например их станет меньше на порядок) то лучше IDE с зеркалкой. Но в стоимость IDE решения надо включать как минимум один запасной диск и время простоя. В реальности событий диски с низкой надёжностью можно использовать даже для промышленных систем хранения данных, и работать они будут быстро (там правда и pentium4 используется в качестве микроконтроллера). Всё дело в реализации и объёме данных (и денег). http://www.citforum.ru/hardware/data/tb_box.shtml Харошие инженеры, есть к сожалению не у всех, да и системы хранения енти далеко не того масштаба. А так конечно ежели деньги есть то SCSI лучше --- гемороя меньше.
Многие говоря о иде требуют обязательного наличия резервирования - мол обязательно иметь пару про запас. На самом деле все как раз наоборот - новый иде диск приобретается сегодня в течении часа (не говоря о том, что его можно сдернуть с рядом стоящего десктопа, и как-то заткнуть дыру на время), а вот за SCSI придется побегать (в лучшем случае), либо на заказ ждать не один день, а то и месяц. Простои считайте сами.
Из личного опыта могу посоветовать главное выбирать надежных поставщиков.
Конечно некачественный SCSI диск найти труднее, чем IDE, но и такое бывает.
Были случаи, что SCSI вылетал через пару месяцев, но были, что IDE поставили временно "на сколько хватит", а он работет уже года четыре постоянно отдавая файлы, причем меньше 500 висящих httpd там редко бывало. Но нужно сказать, этот IDE был с брэндового сервака, что не тоже самое, чем завалены прилавки салонов.Хватает денег или повышенные требования к надежности и производительности - берем не задумываясь SCSI, нет денег или данные не особо жалко - берем _хороший_ IDE (сейчас SATA).
Под каждый случай свои требования.... Про IDE правда, как максимум сутки и он у тебя, потом Т времени гемороя и всё чикипуки. И SCSI гавёные бывают иногда... Просто в SCSI плотность записи как правило меньше в связи с чем надёжность по определению больше, но там и скоростть вращения и механика пошустрее, тоже есть чему сломаться. А нужные данные надо резервировать...
это максимальное время наработки на отказ, я просто неточно выразился, надеюсь кто понял - тот понял.короче, чтобы не раздувать флейм, еще раз другими словами: сравнивать как это делает автор статьи 1xIDE и NxSCSI аппаратный RAID(64m cache) - просто глупо; tagged queue если и снижает износ механики то никак не "на порядки" - есть другие методы на фоне которых этот нивелируется; далее из личного опыта: IDE винты - вполне надежное решение, зеркало на 200 гигов + контроллер + даже 2 запасных винта в заначку и hot-swap корзина стОят минимум в 3 раза дешевле аналогичного решения на SCSI, практически не уступая ему в производительности.
Тем, кто не знаком с теорией надежности: Есть такой показатель надежности, как интенсивность отказов. Так вот, он меняется в зависимости от времени не линейно. И максимальные значения достигаются в начале жизни(в нашем случае - харда) и в конце. Производитель знает это, но... :) тестировать на отказ хард он тоже не может долго - это не рентабельно. Поэтому диски для массового рынка по надежности отличаются от тех, что идут в сектор для серьезных решений. Простой пример, на DEC Alpha(хорошая была RISC платформа) ставились модули со SCSI дисками, по цене превосходящей розничный вариант того же самого SCSI диска в 3-4(!!!) раза. Почему? Да потому что их оттестировали положенное по этой самой теории надежности время. А время у буржуев - деньги! ;)Так вот мой вам совет, если хотите сэкономить часть стоимости "надежного" диска - оттестируйте его на отказ сами. Гарантия на диск дает вам право в случае чего его заменить. Я делаю это так, прежде чем ставить нулевый, только что купленный диск в сервер, я устанавливаю его на пару месяцев в машинку дизайнеров под свопы, либо ставлю в выделенную специально для этих целей машинку и запускаю изнурительный тест с произвольным записью/чтением. Время тестирования? Оно зависит от оценочного времени жизни диска в вашей системе при вашей нагрузке. А здесь уже знакомьтесь с Теорией Надежности лично, куда копать я вам подсказал.
Poprobuite otkrit dir s 50.000 files na ide i na scsi. Rezultat sam za sebia vsio skazhet.
Analogija dir dlia imap...
P.S. (Prostite za ptichki ... u laptopa net RU razkladki)