forum.opennet.ru - "OpenNews: SCSI против IDE, разбор преимуществ SCSI." (41)

форумы

помощь

поиск

регистрация

майллист

ВХОД

слежка

"OpenNews: SCSI против IDE, разбор преимуществ SCSI."

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Архивированная нить - только для чтения! Пред. тема \| След. тема
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: SCSI против IDE, разбор преимуществ SCSI."
Сообщение от opennews on 10-Ноя-04, 22:16
Сравнение IDE и SCSI с объяснением причин высокой стоимости SCSI дисков, и почему платить за них часто оправдано. URL: http://freesource.info/wiki/Zachem_Nam_SCSI Новость: https://www.opennet.ru/opennews/art.shtml?num=4634
Cообщить модератору \| Наверх \| ^

Оглавление

SCSI против IDE, разбор преимуществ SCSI., Дмитрий Ю. Карпов, 22:16 , 10-Ноя-04, (1)

SCSI против IDE, разбор преимуществ SCSI., Sampan, 00:36 , 11-Ноя-04, (2)

SCSI против IDE, разбор преимуществ SCSI., Аноним, 06:37 , 11-Ноя-04, (3)
SCSI против IDE, разбор преимуществ SCSI., necrophagophobiac, 06:38 , 11-Ноя-04, (4)

SCSI против IDE, разбор преимуществ SCSI., Дмитрий Молчанов, 13:00 , 11-Ноя-04, (15)

SCSI против IDE, разбор преимуществ SCSI., necrophagophobiac, 13:46 , 11-Ноя-04, (16)

SCSI против IDE, разбор преимуществ SCSI., Andrey, 09:27 , 11-Ноя-04, (6)

SCSI против IDE, разбор преимуществ SCSI., KG, 11:52 , 11-Ноя-04, (11)

SCSI против IDE, разбор преимуществ SCSI., Tim, 09:18 , 11-Ноя-04, (5)
SCSI против IDE, разбор преимуществ SCSI., jonatan, 10:11 , 11-Ноя-04, (7)

SCSI против IDE, разбор преимуществ SCSI., Roman, 21:37 , 12-Ноя-04, (30)

SCSI против IDE, разбор преимуществ SCSI., c0x, 11:00 , 13-Ноя-04, (32)

SCSI против IDE, разбор преимуществ SCSI., Roman, 12:31 , 14-Ноя-04, (34)

SCSI против IDE, разбор преимуществ SCSI., jonatan, 09:17 , 16-Ноя-04, (39)

SCSI против IDE, разбор преимуществ SCSI., c0x, 13:37 , 16-Ноя-04, (40)

SCSI против IDE, разбор преимуществ SCSI., c0x, 13:47 , 16-Ноя-04, (41)

SCSI против IDE, разбор преимуществ SCSI., c0x, 13:58 , 16-Ноя-04, (42)

SCSI против IDE, разбор преимуществ SCSI., Nikolai, 09:59 , 12-Ноя-04, (26)

SCSI против IDE, разбор преимуществ SCSI., klalafuda, 10:51 , 11-Ноя-04, (8)

SCSI против IDE, разбор преимуществ SCSI., TaranTuL, 11:10 , 11-Ноя-04, (9)

SCSI против IDE, разбор преимуществ SCSI., dryupitz, 12:26 , 11-Ноя-04, (13)

SCSI против IDE, разбор преимуществ SCSI., c0x, 11:36 , 11-Ноя-04, (10)

SCSI против IDE, разбор преимуществ SCSI., co6aka, 12:55 , 11-Ноя-04, (14)

SCSI против IDE, разбор преимуществ SCSI., c0x, 14:47 , 11-Ноя-04, (17)

SCSI против IDE, разбор преимуществ SCSI., klalafuda, 15:56 , 11-Ноя-04, (19)

SCSI против IDE, разбор преимуществ SCSI., c0x, 11:13 , 13-Ноя-04, (33)

SCSI против IDE, разбор преимуществ SCSI., klalafuda, 13:31 , 14-Ноя-04, (35)

SCSI против IDE, разбор преимуществ SCSI., c0x, 08:58 , 15-Ноя-04, (36)

SCSI против IDE, разбор преимуществ SCSI., klalafuda, 10:42 , 15-Ноя-04, (37)

SCSI против IDE, разбор преимуществ SCSI., c0x, 12:04 , 15-Ноя-04, (38)

SCSI против IDE, разбор преимуществ SCSI., GliNT, 15:11 , 11-Ноя-04, (18)

SCSI против IDE, разбор преимуществ SCSI., xz, 12:00 , 11-Ноя-04, (12)

SCSI против IDE, разбор преимуществ SCSI., co6aka, 16:01 , 11-Ноя-04, (20)

SCSI против IDE, разбор преимуществ SCSI., GliNT, 16:24 , 11-Ноя-04, (21)

SCSI лучше но дороже., ZOD, 19:13 , 11-Ноя-04, (22)

SCSI лучше но дороже., Hawk, 21:00 , 12-Ноя-04, (28)

SCSI лучше но дороже., uldus, 21:27 , 12-Ноя-04, (29)

Про то и разговор.... Разное бывает. , ZOD, 01:24 , 13-Ноя-04, (31)

SCSI против IDE, разбор преимуществ SCSI., c0x, 22:20 , 11-Ноя-04, (23)

Немного теории и советы для практики., Pasha, 11:32 , 26-Ноя-04, (43)
SCSI против IDE, разбор преимуществ SCSI., Аноним, 22:19 , 30-Дек-04, (44)

Сообщения по теме [Сортировка по времени, UBB]

1. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Дмитрий Ю. Карпов on 10-Ноя-04, 22:16

Статья содержит ряд фатальных глупостей.
Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум. А оптимизация записи диском при использовании транзакций вообще недопутима (хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD модифицируются транзакционно.

> Вывод 1: SCSI полезно и на серверах, и на рабочих станциях.
Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее.

> Вывод 2: линейная скорость чтения далеко не самое важное
В прайсах указывают спорость вращения диска, а не линейную скорость чтения. Так что имеющий глаза этот второй вывод уже сделал.

Cообщить модератору | Наверх | ^

2. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Sampan on 11-Ноя-04, 00:36

>Статья содержит ряд фатальных глупостей.
Не мешало бы добавить, что это IMHO Дмитрия Ю. Карпова, который, как и все смертные, может ошибаться (просто сам об этом забыл, наверное)
>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум
Продолжая это рассуждение, приходим к выводу, что софтверный RAID предпочтительнее "железного". Без коментариев...
>Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее.
К сожалению, в статье ни чего не сказано о том, что Tagged Queue на порядки увеличивает срок службы диска за счет значительно меньших и более "плавных" перемещений головок (механика - самое слабое место любых дисков).
Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE диски раз в пару месяцев. На прокси сервере под Squid для 250 активных юзеров IDE диски рассыпаются моментально.
Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный. В большинстве случаев надежность важнее!

Cообщить модератору | Наверх | ^

3. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Аноним on 11-Ноя-04, 06:37

>>Статья содержит ряд фатальных глупостей.
>
>Не мешало бы добавить, что это IMHO Дмитрия Ю. Карпова, который, как
>и все смертные, может ошибаться (просто сам об этом забыл, наверное)
>
>
>>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум
>
>Продолжая это рассуждение, приходим к выводу, что софтверный RAID предпочтительнее "железного". Без
>коментариев...
>
>>Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее.
>
>К сожалению, в статье ни чего не сказано о том, что Tagged
>Queue на порядки увеличивает срок службы диска за счет значительно меньших
>и более "плавных" перемещений головок (механика - самое слабое место любых
>дисков).
>
>Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE
>диски раз в пару месяцев. На прокси сервере под Squid для
>250 активных юзеров IDE диски рассыпаются моментально.
>
>Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный.
>В большинстве случаев надежность важнее!
У sata есть tcq/ncq и вообще можно в зеркало поставить, что будет надежней, чем один сказюк.

Cообщить модератору | Наверх | ^

4. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от necrophagophobiac on 11-Ноя-04, 06:38

а что, на IDE-винчестеры гарантия 1 месяц? 8-I

Cообщить модератору | Наверх | ^

15. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Дмитрий Молчанов on 11-Ноя-04, 13:00

>а что, на IDE-винчестеры гарантия 1 месяц? 8-I
А время простоя и нервы потраченные на кусание локтей пока рэйд в degraded mode и ищется новый винт на замену ибо сдох hot spare из 10ки и не в первый раз тоже по гарантии меняются, а время простоя компенсируется? ;)

Cообщить модератору | Наверх | ^

16. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от necrophagophobiac on 11-Ноя-04, 13:46

в случае с IDE пара запасных дисков покупается про запас.

Cообщить модератору | Наверх | ^

6. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Andrey (??) on 11-Ноя-04, 09:27

>Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE
>диски раз в пару месяцев. На прокси сервере под Squid для
>250 активных юзеров IDE диски рассыпаются моментально.
>
>Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный.
>В большинстве случаев надежность важнее!
Простите, а на сколько "мгновенно"? У меня ~300 пользователей и IDE под Squid работает уже 3 года... Когда ждать краха?

Cообщить модератору | Наверх | ^

11. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от KG (??) on 11-Ноя-04, 11:52

не скажу про все диски .. но вот Макстор из глючной партии развалился через год =8-)))

Cообщить модератору | Наверх | ^

5. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Tim (??) on 11-Ноя-04, 09:18

>Оптимизация обращений при чтении д.б. выполнена операционкой, да так,
А разве операционки не оперируют с логическим IDE диском который для нее выглядит линейно (LBA) ? Операционка не может точно знать сколько рабочих поверхностей внутри диска, куда перемещены сбойные области и прочие тонкости позиционирования головок.

Cообщить модератору | Наверх | ^

7. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от jonatan on 11-Ноя-04, 10:11

>А оптимизация записи диском при использовании транзакций вообще недопутима
>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD
>модифицируются транзакционно.
Для любых журналов транзакций (БД, файловых систем и т.п.) важно, чтобы данные этих журналов РЕАЛЬНО были записаны на диск. Поэтому очень рекомендуется отключать кэширование записи. А как выполняется сама запись (оптимизировано или нет) не важно.

Cообщить модератору | Наверх | ^

30. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Roman (??) on 12-Ноя-04, 21:37

>>А оптимизация записи диском при использовании транзакций вообще недопутима
>>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD
>>модифицируются транзакционно.
>
>Для любых журналов транзакций (БД, файловых систем и т.п.) важно, чтобы данные
>этих журналов РЕАЛЬНО были записаны на диск. Поэтому очень рекомендуется отключать
>кэширование записи. А как выполняется сама запись (оптимизировано или нет) не
>важно.
если мы говорим о external hardware raid, то там должен стоять аккумулятор, которого должно быть достаточно ровно для того, чтобы держать кэш до тех пор пока не будут устранены проблемы (например A1000 от Sun, помнит содержимое кэша 72 часа)

Cообщить модератору | Наверх | ^

32. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 13-Ноя-04, 11:00

вообще, батарейки на кэше контроллера вещь довольно сомнительная. если быть последовательным, нужно также сохранять кеш HDD или отключать кеширование на запись (производительность), а еще лучше делать как SUN в своих T3 массивах - аккумулятор держит весь девайс в апе, эдакий внутренний UPS. А пока держит, рекомендуется зайти в него с консоли и сделать шатдаун.

Cообщить модератору | Наверх | ^

34. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Roman (??) on 14-Ноя-04, 12:31

согласен, но тогда, в некотором смысле, ситуация тупиковая - оптимизировать движение головок может только контроллер самого диска, а в случае проблем с механикой "отключить" его на время ремонта/замены механики, "попросив не забывать" кэш, невозможно.

Cообщить модератору | Наверх | ^

39. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от jonatan on 16-Ноя-04, 09:17

Поясните кто знает следующее. Есть сервер HP со встроенным SCSI RAID-контроллером. Управлять кэшированием можно только на логическом томе (например, RAID1), для чего используется память контроллера (32M). Нигде не смог найти, как отключить/включить кэш самих HDD. Как выяснить, работает он, например, на запись или нет?

Cообщить модератору | Наверх | ^

40. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 16-Ноя-04, 13:37

Возможно, управление кэшированием в таком случае иерархическое: от логического тома до отдельных дисков. Например при "отложенной записи" на логическое устройство запись производится в кэш контроллера и контроллер сразу сообщает хосту об успешно завершенной операции. Далее уже в фоне происходит запись на диски, возможно тоже в режиме "write back", но не обязательно. При "сквозной записи" контроллер не вернет ОК до тех пор, пока данные физически не запишутся на носитель. В свою очередь сам контроллер ожидает подтверждение успешно выполненной операции от каждого диска в массиве, причем и диски работают в режиме "сквозной записи".
Возможны варианты:
том wb: контроллер - wb, диски - wb
том wb: контроллер - wt, диски - wb
том wb: контроллер - wb, диски - wt
том wt: контроллер - wt, диски - wb
том wt: контроллер - wt, диски - wt
первый вариант самый быстрый, последний - самый надежный.
конкретная реализация схемы зависит от контроллера.

>Поясните кто знает следующее. Есть сервер HP со встроенным SCSI RAID-контроллером. Управлять
>кэшированием можно только на логическом томе (например, RAID1), для чего используется
>память контроллера (32M). Нигде не смог найти, как отключить/включить кэш самих
>HDD. Как выяснить, работает он, например, на запись или нет?

Cообщить модератору | Наверх | ^

41. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 16-Ноя-04, 13:47

поправка:
том wb: контроллер - wb, диски - wb
том wb: контроллер - wb, диски - wt
том wt: контроллер - wt, диски - wb
том wt: контроллер - wt, диски - wt
И кстати, даже если том в режиме wb кеширования, можно заставить некоторые операции производить в режиме wt, для этого есть специальные команды и/или флаги. Например для записи метаданных ядром.

Cообщить модератору | Наверх | ^

42. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 16-Ноя-04, 13:58

вот еще по теме режимов кэширования:
http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-43654

Cообщить модератору | Наверх | ^

26. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Nikolai (??) on 12-Ноя-04, 09:59

>Статья содержит ряд фатальных глупостей.
>
>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском
>давала минимум. А оптимизация записи диском при использовании транзакций вообще недопутима
>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD
>модифицируются транзакционно.
>
>
>> Вывод 1: SCSI полезно и на серверах, и на рабочих станциях.
>
>Естественно, полезно. Если только мы не думаем о том, что деньгами можно
>распорядиться умнее.
>
>
>> Вывод 2: линейная скорость чтения далеко не самое важное
>
>В прайсах указывают спорость вращения диска, а не линейную скорость чтения. Так
>что имеющий глаза этот второй вывод уже сделал.
Ваши высказывания содержат ряд фатальных глупостей, как выраженных здесь, по поводу SCSI дисков, так и по почтовым делам, ваш юношеский задор просто раздражает, глубина вашего незнания просто поражает воображение, а безапеляционные высказывания претендующие на истину в последней инстанции просто бесят. Вам бы лучше Windows пользоваться.
А насчёт дисков SCSI скажу, если действительно требуется высокая производительность с минимальными нагрузками на систему, в том числе и на проц, то лучше SCSI ничего нет.

Cообщить модератору | Наверх | ^

8. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от klalafuda on 11-Ноя-04, 10:51

"разбор" - это конечно очень сильно сказано :) автор просто гений пера и выражения мысли..
а то, что колбаса из мяса лучше, чем соевая.. дык г*&^$% вопрос! никто и не собирается спорить :) конечно лучше.
// wbr

Cообщить модератору | Наверх | ^

9. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от TaranTuL on 11-Ноя-04, 11:10

>
>"разбор" - это конечно очень сильно сказано :) автор просто гений пера
>и выражения мысли..
>
>а то, что колбаса из мяса лучше, чем соевая.. дык г*&^$% вопрос!
>никто и не собирается спорить :) конечно лучше.
>
>// wbr

Вегетарьянцы с тобой будут спорить :)

Cообщить модератору | Наверх | ^

13. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от dryupitz on 11-Ноя-04, 12:26

>Вегетарьянцы с тобой будут спорить :)
Говорят что "вегетарианец" в переводе с санскрита означает "плохой охотник" :)

Cообщить модератору | Наверх | ^

10. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 11-Ноя-04, 11:36

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

Cообщить модератору | Наверх | ^

14. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от co6aka (??) on 11-Ноя-04, 12:55

4c0x:
П.2 А не рубите ли вы сплеча... ide диски(механика) в большинстве своем не расчитаны(производитель не заявляет об этом) на безостановочную работу круглые сутки семь дней в неделю и т.д.  А далее... 250 юзеров на проксе... :) условия то разные... например с каналом в 128кб :)))) вообоще мало что загнется.

Cообщить модератору | Наверх | ^

17. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 11-Ноя-04, 14:47

причем тут сутки,неделя и тд. есть стандартные вещи для оценки бесперебойной работы железки: MTBF порядка 500-700 килочасов у современных винтов, собранных не в венгрии или болгарии.
а насчет сквида, частых перемещений головок диска и "..Tagged
Queue на порядки увеличивает срок службы.." приведу следующие доводы:
1. умейте настроить сквид так чтобы винты жили дольше (хинт: оно любит много RAM)
2. в случае с bsd/linux существует оптимизация перемещения головок на уровне ОС, и не забывайте про системный кэш и ufs_dirhash/softupdates во фре.

Cообщить модератору | Наверх | ^

19. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от klalafuda on 11-Ноя-04, 15:56

>причем тут сутки,неделя и тд. есть стандартные вещи для оценки бесперебойной работы
>железки: MTBF порядка 500-700 килочасов у современных винтов, собранных не в
>венгрии или болгарии.
таки есть MTBF а есть режим работы. это две разные вещи.
>2. в случае с bsd/linux существует оптимизация перемещения головок на уровне ОС,
>и не забывайте про системный кэш и ufs_dirhash/softupdates во фре.
в вот тут можно чуть подробнее?
// wbr

Cообщить модератору | Наверх | ^

33. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 13-Ноя-04, 11:13

>в вот тут можно чуть подробнее?
подробнее тут: http://fxr.watson.org/fxr/source/kern

Cообщить модератору | Наверх | ^

35. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от klalafuda on 14-Ноя-04, 13:31

>>в вот тут можно чуть подробнее?
>
>подробнее тут: http://fxr.watson.org/fxr/source/kern
очень содержательный ответ, большое вам за него человеческое спасибо :)
а можно все то-же, но в более человеческих терминах? например, ссылка в пределах www.t13.org была бы заметно полезнее.
anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними связь?
хотя я и не использую FreeBSD, но все-таки отношусь с большим уважением к FreeBSD Team, равно как и верю в их разум и вменяемость. и хоть убейте но не поверю, что *это* (даже если оно и существует) сделано в указанной части дерева исходников ядра.
// wbr

Cообщить модератору | Наверх | ^

36. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 15-Ноя-04, 08:58

>anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для
>FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними
>связь?
http://fxr.watson.org/fxr/source/kern/subr_disk.c#L127

Cообщить модератору | Наверх | ^

37. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от klalafuda on 15-Ноя-04, 10:42

>>anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для
>>FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними
>>связь?
>
>http://fxr.watson.org/fxr/source/kern/subr_disk.c#L127
если я правильно понимаю ситуацию, это аналог/переработка disksort() из оригинальной BSD:
---cut---
Sorting of Disk I/O Requests
The 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

Cообщить модератору | Наверх | ^

38. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 15-Ноя-04, 12:04

>вопрос собссно - вы уверены, что это все еще имеет практический смысл
>с точки зрения оптимизации движения головок на современном 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.pdf
(http://fxr.watson.org/fxr/source/dev/pst/pst-raid.c#L204)
И не только *BSD и линукс. Например Novell NetWare.

Cообщить модератору | Наверх | ^

18. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от GliNT (??) on 11-Ноя-04, 15:11

>3. tagged queue поддерживали некоторые IDE диски от  IBM (кажется серия
>DTLA).
>
Диски семейства Vancoover 2 поддерживают TCQ.
Их и надо сравнивать со SCSI.

Cообщить модератору | Наверх | ^

12. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от xz (??) on 11-Ноя-04, 12:00

ага на фрии бсд он мож и быстрее ))))

Cообщить модератору | Наверх | ^

20. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от co6aka (ok) on 11-Ноя-04, 16:01

Может я ошибаюсь,но imho MTBF это не время бесперебойной работы...
А время наработки на отказ при соблюдении условий эксплуатиции устройства.

Cообщить модератору | Наверх | ^

21. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от GliNT (??) on 11-Ноя-04, 16:24

> Может я ошибаюсь,но imho MTBF это не время бесперебойной работы...
>А время наработки на отказ при соблюдении условий эксплуатиции устройства.
Ошибаетесь, это СРЕДНЕЕ время наработки на отказ.
Вычисляется по неким статистическим формулам, никто реально не ждет столько времени для проверки этого значения.
Еще есть такие параметры, как количество запусков/остановок, число считанных/записанных бит до появления неустранимой ошибки.
Например у Hitachi Deskstar 180GXP параметры такие:
количество запусков/остановок: 40.000,
число считанных/записанных бит до появления неустранимой ошибки: 1*10E14.
Кстати, гарантия на этот HDD у них 1 год, а у SCSI-винчестеров - 5 лет. Кстати, раньше(2002 год) на IDE-винчестеры было 3 года гарантии.

Cообщить модератору | Наверх | ^

22. "SCSI лучше но дороже."

Сообщение от ZOD (ok) on 11-Ноя-04, 19:13

Везде нужно правильно выбирать. Если вместо покупки SCSI дисков нужного объёма Вы можете купить IDE и Гиг оперативки, и этого Гига хватит для минимизации обращений к диску (например их станет меньше на порядок) то лучше IDE с зеркалкой. Но в стоимость IDE решения надо включать как минимум один запасной диск и время простоя. В реальности событий диски с низкой надёжностью можно использовать даже для промышленных систем хранения данных, и работать они будут быстро (там правда и pentium4 используется в качестве микроконтроллера). Всё дело в реализации и объёме данных (и денег). http://www.citforum.ru/hardware/data/tb_box.shtml Харошие инженеры, есть к сожалению не у всех, да и системы хранения енти далеко не того масштаба. А так конечно ежели деньги есть то SCSI лучше --- гемороя меньше.

Cообщить модератору | Наверх | ^

28. "SCSI лучше но дороже."

Сообщение от Hawk (??) on 12-Ноя-04, 21:00

Многие говоря о иде требуют обязательного наличия резервирования - мол обязательно иметь пару про запас. На самом деле все как раз наоборот - новый иде диск приобретается сегодня в течении часа (не говоря о том, что его можно сдернуть с рядом стоящего десктопа, и как-то заткнуть дыру на время), а вот за SCSI придется побегать (в лучшем случае), либо на заказ ждать не один день, а то и месяц. Простои считайте сами.

Cообщить модератору | Наверх | ^

29. "SCSI лучше но дороже."

Сообщение от uldus (ok) on 12-Ноя-04, 21:27

Из личного опыта могу посоветовать главное выбирать надежных поставщиков.
Конечно некачественный SCSI диск найти труднее, чем IDE, но и такое бывает.
Были случаи, что SCSI вылетал через пару месяцев, но были, что IDE поставили временно "на сколько хватит", а он работет уже года четыре постоянно отдавая файлы, причем меньше 500 висящих httpd там редко бывало. Но нужно сказать, этот IDE был с брэндового сервака, что не тоже самое, чем завалены прилавки салонов.
Хватает денег или повышенные требования к надежности и производительности - берем не задумываясь SCSI, нет денег или данные не особо жалко - берем _хороший_ IDE (сейчас SATA).

Cообщить модератору | Наверх | ^

31. "Про то и разговор.... Разное бывает. "

Сообщение от ZOD (??) on 13-Ноя-04, 01:24

Под каждый случай свои требования.... Про IDE правда, как максимум сутки и он у тебя, потом Т времени гемороя и всё чикипуки. И SCSI гавёные бывают иногда... Просто в SCSI плотность записи как правило меньше в связи с чем надёжность по определению больше, но там и скоростть вращения и механика пошустрее, тоже есть чему сломаться. А нужные данные надо резервировать...

Cообщить модератору | Наверх | ^

23. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от c0x (??) on 11-Ноя-04, 22:20

это максимальное время наработки на отказ, я просто неточно выразился, надеюсь кто понял - тот понял.
короче, чтобы не раздувать флейм, еще раз другими словами: сравнивать как это делает автор статьи 1xIDE и NxSCSI аппаратный RAID(64m cache) - просто глупо; tagged queue если и снижает износ механики то никак не "на порядки" - есть другие методы на фоне которых этот нивелируется;  далее из личного опыта: IDE винты - вполне надежное решение, зеркало на 200 гигов + контроллер + даже 2 запасных винта в заначку и hot-swap корзина стОят минимум в 3 раза дешевле аналогичного решения на SCSI, практически не уступая ему в производительности.

Cообщить модератору | Наверх | ^

43. "Немного теории и советы для практики."

Сообщение от Pasha (??) on 26-Ноя-04, 11:32

Тем, кто не знаком с теорией надежности: Есть такой показатель надежности, как интенсивность отказов. Так вот, он меняется в зависимости от времени не линейно. И максимальные значения достигаются в начале жизни(в нашем случае - харда) и в конце. Производитель знает это, но... :) тестировать на отказ хард он тоже не может долго - это не рентабельно. Поэтому диски для массового рынка по надежности отличаются от тех, что идут в сектор для серьезных решений. Простой пример, на DEC Alpha(хорошая была RISC платформа) ставились модули со SCSI дисками, по цене превосходящей розничный вариант того же самого SCSI диска в 3-4(!!!) раза. Почему? Да потому что их оттестировали положенное по этой самой теории надежности время. А время у буржуев - деньги! ;)Так вот мой вам совет, если хотите сэкономить часть стоимости "надежного" диска - оттестируйте его на отказ сами. Гарантия на диск дает вам право в случае чего его заменить. Я делаю это так, прежде чем ставить нулевый, только что купленный диск в сервер, я устанавливаю его на пару месяцев в машинку дизайнеров под свопы, либо ставлю в выделенную специально для этих целей машинку и запускаю изнурительный тест с произвольным записью/чтением. Время тестирования? Оно зависит от оценочного времени жизни диска в вашей системе при вашей нагрузке. А здесь уже знакомьтесь с Теорией Надежности лично, куда копать я вам подсказал.

Cообщить модератору | Наверх | ^

44. "SCSI против IDE, разбор преимуществ SCSI."

Сообщение от Аноним on 30-Дек-04, 22:19

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)

Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "SCSI против IDE, разбор преимуществ SCSI."
Сообщение от Дмитрий Ю. Карпов on 10-Ноя-04, 22:16
Статья содержит ряд фатальных глупостей. Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум. А оптимизация записи диском при использовании транзакций вообще недопутима (хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD модифицируются транзакционно. > Вывод 1: SCSI полезно и на серверах, и на рабочих станциях. Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее. > Вывод 2: линейная скорость чтения далеко не самое важное В прайсах указывают спорость вращения диска, а не линейную скорость чтения. Так что имеющий глаза этот второй вывод уже сделал.
Cообщить модератору \| Наверх \| ^


	2. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Sampan on 11-Ноя-04, 00:36
	>Статья содержит ряд фатальных глупостей. Не мешало бы добавить, что это IMHO Дмитрия Ю. Карпова, который, как и все смертные, может ошибаться (просто сам об этом забыл, наверное) >Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум Продолжая это рассуждение, приходим к выводу, что софтверный RAID предпочтительнее "железного". Без коментариев... >Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее. К сожалению, в статье ни чего не сказано о том, что Tagged Queue на порядки увеличивает срок службы диска за счет значительно меньших и более "плавных" перемещений головок (механика - самое слабое место любых дисков). Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE диски раз в пару месяцев. На прокси сервере под Squid для 250 активных юзеров IDE диски рассыпаются моментально. Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный. В большинстве случаев надежность важнее!
	Cообщить модератору \| Наверх \| ^


	3. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Аноним on 11-Ноя-04, 06:37
	>>Статья содержит ряд фатальных глупостей. > >Не мешало бы добавить, что это IMHO Дмитрия Ю. Карпова, который, как >и все смертные, может ошибаться (просто сам об этом забыл, наверное) > > >>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском давала минимум > >Продолжая это рассуждение, приходим к выводу, что софтверный RAID предпочтительнее "железного". Без >коментариев... > >>Естественно, полезно. Если только мы не думаем о том, что деньгами можно распорядиться умнее. > >К сожалению, в статье ни чего не сказано о том, что Tagged >Queue на порядки увеличивает срок службы диска за счет значительно меньших >и более "плавных" перемещений головок (механика - самое слабое место любых >дисков). > >Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE >диски раз в пару месяцев. На прокси сервере под Squid для >250 активных юзеров IDE диски рассыпаются моментально. > >Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный. >В большинстве случаев надежность важнее! У sata есть tcq/ncq и вообще можно в зеркало поставить, что будет надежней, чем один сказюк.
	Cообщить модератору \| Наверх \| ^


	4. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от necrophagophobiac on 11-Ноя-04, 06:38
	а что, на IDE-винчестеры гарантия 1 месяц? 8-I
	Cообщить модератору \| Наверх \| ^


	15. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Дмитрий Молчанов on 11-Ноя-04, 13:00
	>а что, на IDE-винчестеры гарантия 1 месяц? 8-I А время простоя и нервы потраченные на кусание локтей пока рэйд в degraded mode и ищется новый винт на замену ибо сдох hot spare из 10ки и не в первый раз тоже по гарантии меняются, а время простоя компенсируется? ;)
	Cообщить модератору \| Наверх \| ^


	16. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от necrophagophobiac on 11-Ноя-04, 13:46
	в случае с IDE пара запасных дисков покупается про запас.
	Cообщить модератору \| Наверх \| ^


	6. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Andrey (??) on 11-Ноя-04, 09:27
	>Мне доводилось видеть думающих, "что деньгами можно распорядиться умнее", которые меняли IDE >диски раз в пару месяцев. На прокси сервере под Squid для >250 активных юзеров IDE диски рассыпаются моментально. > >Так что, вывод, "линейная скорость чтения далеко не самое важное" очень правильный. >В большинстве случаев надежность важнее! Простите, а на сколько "мгновенно"? У меня ~300 пользователей и IDE под Squid работает уже 3 года... Когда ждать краха?
	Cообщить модератору \| Наверх \| ^


	11. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от KG (??) on 11-Ноя-04, 11:52
	не скажу про все диски .. но вот Макстор из глючной партии развалился через год =8-)))
	Cообщить модератору \| Наверх \| ^


	5. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Tim (??) on 11-Ноя-04, 09:18
	>Оптимизация обращений при чтении д.б. выполнена операционкой, да так, А разве операционки не оперируют с логическим IDE диском который для нее выглядит линейно (LBA) ? Операционка не может точно знать сколько рабочих поверхностей внутри диска, куда перемещены сбойные области и прочие тонкости позиционирования головок.
	Cообщить модератору \| Наверх \| ^


	7. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от jonatan on 11-Ноя-04, 10:11
	>А оптимизация записи диском при использовании транзакций вообще недопутима >(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD >модифицируются транзакционно. Для любых журналов транзакций (БД, файловых систем и т.п.) важно, чтобы данные этих журналов РЕАЛЬНО были записаны на диск. Поэтому очень рекомендуется отключать кэширование записи. А как выполняется сама запись (оптимизировано или нет) не важно.
	Cообщить модератору \| Наверх \| ^


	30. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Roman (??) on 12-Ноя-04, 21:37
	>>А оптимизация записи диском при использовании транзакций вообще недопутима >>(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD >>модифицируются транзакционно. > >Для любых журналов транзакций (БД, файловых систем и т.п.) важно, чтобы данные >этих журналов РЕАЛЬНО были записаны на диск. Поэтому очень рекомендуется отключать >кэширование записи. А как выполняется сама запись (оптимизировано или нет) не >важно. если мы говорим о external hardware raid, то там должен стоять аккумулятор, которого должно быть достаточно ровно для того, чтобы держать кэш до тех пор пока не будут устранены проблемы (например A1000 от Sun, помнит содержимое кэша 72 часа)
	Cообщить модератору \| Наверх \| ^


	32. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 13-Ноя-04, 11:00
	вообще, батарейки на кэше контроллера вещь довольно сомнительная. если быть последовательным, нужно также сохранять кеш HDD или отключать кеширование на запись (производительность), а еще лучше делать как SUN в своих T3 массивах - аккумулятор держит весь девайс в апе, эдакий внутренний UPS. А пока держит, рекомендуется зайти в него с консоли и сделать шатдаун.
	Cообщить модератору \| Наверх \| ^


	34. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Roman (??) on 14-Ноя-04, 12:31
	согласен, но тогда, в некотором смысле, ситуация тупиковая - оптимизировать движение головок может только контроллер самого диска, а в случае проблем с механикой "отключить" его на время ремонта/замены механики, "попросив не забывать" кэш, невозможно.
	Cообщить модератору \| Наверх \| ^


	39. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от jonatan on 16-Ноя-04, 09:17
	Поясните кто знает следующее. Есть сервер HP со встроенным SCSI RAID-контроллером. Управлять кэшированием можно только на логическом томе (например, RAID1), для чего используется память контроллера (32M). Нигде не смог найти, как отключить/включить кэш самих HDD. Как выяснить, работает он, например, на запись или нет?
	Cообщить модератору \| Наверх \| ^


	40. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 16-Ноя-04, 13:37
	Возможно, управление кэшированием в таком случае иерархическое: от логического тома до отдельных дисков. Например при "отложенной записи" на логическое устройство запись производится в кэш контроллера и контроллер сразу сообщает хосту об успешно завершенной операции. Далее уже в фоне происходит запись на диски, возможно тоже в режиме "write back", но не обязательно. При "сквозной записи" контроллер не вернет ОК до тех пор, пока данные физически не запишутся на носитель. В свою очередь сам контроллер ожидает подтверждение успешно выполненной операции от каждого диска в массиве, причем и диски работают в режиме "сквозной записи". Возможны варианты: том wb: контроллер - wb, диски - wb том wb: контроллер - wt, диски - wb том wb: контроллер - wb, диски - wt том wt: контроллер - wt, диски - wb том wt: контроллер - wt, диски - wt первый вариант самый быстрый, последний - самый надежный. конкретная реализация схемы зависит от контроллера. >Поясните кто знает следующее. Есть сервер HP со встроенным SCSI RAID-контроллером. Управлять >кэшированием можно только на логическом томе (например, RAID1), для чего используется >память контроллера (32M). Нигде не смог найти, как отключить/включить кэш самих >HDD. Как выяснить, работает он, например, на запись или нет?
	Cообщить модератору \| Наверх \| ^


	41. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 16-Ноя-04, 13:47
	поправка: том wb: контроллер - wb, диски - wb том wb: контроллер - wb, диски - wt том wt: контроллер - wt, диски - wb том wt: контроллер - wt, диски - wt И кстати, даже если том в режиме wb кеширования, можно заставить некоторые операции производить в режиме wt, для этого есть специальные команды и/или флаги. Например для записи метаданных ядром.
	Cообщить модератору \| Наверх \| ^


	42. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 16-Ноя-04, 13:58
	вот еще по теме режимов кэширования: http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-43654
	Cообщить модератору \| Наверх \| ^


	26. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от Nikolai (??) on 12-Ноя-04, 09:59
	>Статья содержит ряд фатальных глупостей. > >Оптимизация обращений при чтении д.б. выполнена операционкой, да так, чтобы оптимизация диском >давала минимум. А оптимизация записи диском при использовании транзакций вообще недопутима >(хочу напомнить, что и NTFS в W'NT, и UFS+SoftUpdates во FreeBSD >модифицируются транзакционно. > > >> Вывод 1: SCSI полезно и на серверах, и на рабочих станциях. > >Естественно, полезно. Если только мы не думаем о том, что деньгами можно >распорядиться умнее. > > >> Вывод 2: линейная скорость чтения далеко не самое важное > >В прайсах указывают спорость вращения диска, а не линейную скорость чтения. Так >что имеющий глаза этот второй вывод уже сделал. Ваши высказывания содержат ряд фатальных глупостей, как выраженных здесь, по поводу SCSI дисков, так и по почтовым делам, ваш юношеский задор просто раздражает, глубина вашего незнания просто поражает воображение, а безапеляционные высказывания претендующие на истину в последней инстанции просто бесят. Вам бы лучше Windows пользоваться. А насчёт дисков SCSI скажу, если действительно требуется высокая производительность с минимальными нагрузками на систему, в том числе и на проц, то лучше SCSI ничего нет.
	Cообщить модератору \| Наверх \| ^

8. "SCSI против IDE, разбор преимуществ SCSI."
Сообщение от klalafuda on 11-Ноя-04, 10:51
"разбор" - это конечно очень сильно сказано :) автор просто гений пера и выражения мысли.. а то, что колбаса из мяса лучше, чем соевая.. дык г*&^$% вопрос! никто и не собирается спорить :) конечно лучше. // wbr
Cообщить модератору \| Наверх \| ^


	9. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от TaranTuL on 11-Ноя-04, 11:10
	> >"разбор" - это конечно очень сильно сказано :) автор просто гений пера >и выражения мысли.. > >а то, что колбаса из мяса лучше, чем соевая.. дык г*&^$% вопрос! >никто и не собирается спорить :) конечно лучше. > >// wbr Вегетарьянцы с тобой будут спорить :)
	Cообщить модератору \| Наверх \| ^


	13. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от dryupitz on 11-Ноя-04, 12:26
	>Вегетарьянцы с тобой будут спорить :) Говорят что "вегетарианец" в переводе с санскрита означает "плохой охотник" :)
	Cообщить модератору \| Наверх \| ^

10. "SCSI против IDE, разбор преимуществ SCSI."
Сообщение от c0x (??) on 11-Ноя-04, 11:36
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
Cообщить модератору \| Наверх \| ^


	14. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от co6aka (??) on 11-Ноя-04, 12:55
	4c0x: П.2 А не рубите ли вы сплеча... ide диски(механика) в большинстве своем не расчитаны(производитель не заявляет об этом) на безостановочную работу круглые сутки семь дней в неделю и т.д. А далее... 250 юзеров на проксе... :) условия то разные... например с каналом в 128кб :)))) вообоще мало что загнется.
	Cообщить модератору \| Наверх \| ^


	17. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 11-Ноя-04, 14:47
	причем тут сутки,неделя и тд. есть стандартные вещи для оценки бесперебойной работы железки: MTBF порядка 500-700 килочасов у современных винтов, собранных не в венгрии или болгарии. а насчет сквида, частых перемещений головок диска и "..Tagged Queue на порядки увеличивает срок службы.." приведу следующие доводы: 1. умейте настроить сквид так чтобы винты жили дольше (хинт: оно любит много RAM) 2. в случае с bsd/linux существует оптимизация перемещения головок на уровне ОС, и не забывайте про системный кэш и ufs_dirhash/softupdates во фре.
	Cообщить модератору \| Наверх \| ^


	19. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от klalafuda on 11-Ноя-04, 15:56
	>причем тут сутки,неделя и тд. есть стандартные вещи для оценки бесперебойной работы >железки: MTBF порядка 500-700 килочасов у современных винтов, собранных не в >венгрии или болгарии. таки есть MTBF а есть режим работы. это две разные вещи. >2. в случае с bsd/linux существует оптимизация перемещения головок на уровне ОС, >и не забывайте про системный кэш и ufs_dirhash/softupdates во фре. в вот тут можно чуть подробнее? // wbr
	Cообщить модератору \| Наверх \| ^


	33. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 13-Ноя-04, 11:13
	>в вот тут можно чуть подробнее? подробнее тут: http://fxr.watson.org/fxr/source/kern
	Cообщить модератору \| Наверх \| ^


	35. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от klalafuda on 14-Ноя-04, 13:31
	>>в вот тут можно чуть подробнее? > >подробнее тут: http://fxr.watson.org/fxr/source/kern очень содержательный ответ, большое вам за него человеческое спасибо :) а можно все то-же, но в более человеческих терминах? например, ссылка в пределах www.t13.org была бы заметно полезнее. anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними связь? хотя я и не использую FreeBSD, но все-таки отношусь с большим уважением к FreeBSD Team, равно как и верю в их разум и вменяемость. и хоть убейте но не поверю, что это (даже если оно и существует) сделано в указанной части дерева исходников ядра. // wbr
	Cообщить модератору \| Наверх \| ^


	36. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 15-Ноя-04, 08:58
	>anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для >FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними >связь? http://fxr.watson.org/fxr/source/kern/subr_disk.c#L127
	Cообщить модератору \| Наверх \| ^


	37. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от klalafuda on 15-Ноя-04, 10:42
	>>anyway. даже в пределах данной ссылки я не понимаю одного.. sys/kern для >>FreeBSD и оптимизация перемещения головок на ATA диске. какая между ними >>связь? > >http://fxr.watson.org/fxr/source/kern/subr_disk.c#L127 если я правильно понимаю ситуацию, это аналог/переработка disksort() из оригинальной BSD: ---cut--- Sorting of Disk I/O Requests The 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
	Cообщить модератору \| Наверх \| ^


	38. "SCSI против IDE, разбор преимуществ SCSI."
	Сообщение от c0x (??) on 15-Ноя-04, 12:04
	>вопрос собссно - вы уверены, что это все еще имеет практический смысл >с точки зрения оптимизации движения головок на современном 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.pdf (http://fxr.watson.org/fxr/source/dev/pst/pst-raid.c#L204) И не только *BSD и линукс. Например Novell NetWare.
	Cообщить модератору \| Наверх \| ^