http://freesource.info/wiki/ЗачемНамSCSI History/revisions of FreeSource/ЗачемНамSCSI en-us http://freesource.info/wiki/ZachemNamSCSI/show?time=2004-12-06+19%3A39%3A59 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".zachemnamscsi" href="http://freesource.info/wiki/ZachemNamSCSI&" class="">/Зачем&nbsp;Нам&nbsp;SCSI</a> за <a href="http://freesource.info/wiki/ZachemNamSCSI?time=2004-12-06+19%3A39%3A59">2004-12-06 19:39:59</a> и <a href="http://freesource.info/wiki/ZachemNamSCSI">2004-12-19 23:23:09</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Эта&nbsp;статья описывает какую пользу может принести пользователю использование <strong>SCSI</strong>-дисков, в&nbsp;том числе на&nbsp;рабочей станции.<br /> Во-первых <strong>SCSI</strong>-диски дороже. В&nbsp;несколько раз.<br /> Во-вторых максимальными размерами &mdash; SATA и&nbsp;IDE диски размером в&nbsp;250Gb встречаются весьма часто, и&nbsp;стоят вполне разумных денег. Стоимость <strong>SCSI</strong>-дисков размером в&nbsp;140G превышает тысячу долларов (1k$)!<br /> <strong>SCSI</strong>-диски продаются со&nbsp;скоростью вращения шпинделя в&nbsp;10'000 и&nbsp;15'000 оборотов в&nbsp;минуту. Против 7'200 максимальной скорости у&nbsp;IDE/SATA дисков (за исключением одного единственного HDD&nbsp;от&nbsp;Western Digital, который и&nbsp;стоит как&nbsp;<strong>SCSI</strong>, и&nbsp;объём имеет небольшой). Это&nbsp;первое преимущество. Собственно высокая цена и&nbsp;маленькие объёмы диктуются, видимо, в&nbsp;первую очередь этим.<br /> У&nbsp;<strong>SCSI</strong> есть ещё одно преимущество, выглядещее очень скромно, но&nbsp;делающее SCSI дисков единственным выбором в&nbsp;большинстве многопользовательских решений и&nbsp;серверов с&nbsp;большой нагрузкой &mdash; <u>очередь запросов</u>.<br /> <strong>SCSI</strong>-диск может получить несколько запросов, после чего выполнить их&nbsp;и передать результат хост-контроллеру в&nbsp;произвольном порядке. Что&nbsp;это означает на&nbsp;практике?<br /> В&nbsp;low-end серверах (к коим и&nbsp;относится подавляющее большинство серверов в&nbsp;xUSSR) на&nbsp;<strong>SCSI</strong>-дисках часто пытаются сэкономить. А&nbsp;зря. В&nbsp;большинстве задач, выполняемых этими самыми low-end серверами, ключевыми для&nbsp;производительности являются оперативная память (её количество) и&nbsp;дисковая подсистема, а&nbsp;процессор является предпоследним (перед видеокартой, разумеется).<br /> Например для&nbsp;корпоративного почтового сервера и&nbsp;intranet/internet сайта (а это&nbsp;одни из&nbsp;самых частых задач для&nbsp;low-end UNIX-серверов) обычно достаточно процессора Pentium III, но&nbsp;512Mb-1Gb памяти и&nbsp;маленький (<span class="nobr">9&ndash;18</span>Gb) &laquo;старенький&raquo; <strong>SCSI</strong> HDD&nbsp;может дать заметный прирост в&nbsp;производительности (на почтовом сервере провайдера или&nbsp;крупной компании это&nbsp;будет видно лучше всего).<br /> В&nbsp;многопользовательских системах, я&nbsp;надеюсь, преимущества <strong>SCSI</strong> уже&nbsp;очевидны.<br /> При&nbsp;такой сборке нагрузка на&nbsp;дисковую подсистему значительна, и&nbsp;использование <strong>SCSI</strong>-диска может ускорить сборку. Кроме того, при&nbsp;быстром процессоре (а уж&nbsp;тем более SMP&nbsp;машине с&nbsp;быстрыми процессорами) это&nbsp;может отразиться на&nbsp;общей &laquo;отзывчивости&raquo; системы.<br /> Факт 2: cvs&nbsp;update на&nbsp;большом дереве исходников процесс весьма долгий. На&nbsp;девелоперском сервере, которым я&nbsp;пользуюсь для&nbsp;разработки, установлен LSI-контроллер с&nbsp;64Mb кэша (с батарейкой) и&nbsp;RAID5 массив из&nbsp;15krpm 36Gb <strong>SCSI</strong> дисков. По&nbsp;сравнению с&nbsp;моей рабочей машиной cvs&nbsp;работает более чем&nbsp;на&nbsp;порядок быстрее. При&nbsp;том что&nbsp;линейная скорость чтения с&nbsp;дисков у&nbsp;моей рабочей машины выше (!).<br /> Ежеминутный поиск всех изменившихся файлов в&nbsp;/ ощутимо тормозит систему, если домашний каталог находится на&nbsp;IDE-диске. На&nbsp;<strong>SCSI</strong>-дисках это&nbsp;абсолютно незаметно. Копирование выполняется на&nbsp;SATA-диск размером 250G (он большой и&nbsp;относильно <strong>SCSI</strong>-дисков недорогой), а&nbsp;сам домашний каталог размещается, естественно, на&nbsp;<strong>SCSI</strong>-дисках.<br /> Оптимальная конфигурация для&nbsp;рабочей станции на&nbsp;сегодняшний день &mdash; маленький <strong>SCSI</strong>-диск (или RAID-массив, смотря по&nbsp;финансовым способностям) для&nbsp;основных рабочих документов и&nbsp;данных и&nbsp;один SATA-диск для&nbsp;мультимедиа-данных и&nbsp;прочих данных большого размера с&nbsp;преимущественно последовательным доступом.<br /> Я&nbsp;долго мечтал о&nbsp;низкооборотных HDD&nbsp;со&nbsp;<strong>SCSI</strong>-интерфейсом, и&nbsp;моя мечта почти сбылась. TCQ&nbsp;(Tagged Command Queue) является одной из&nbsp;возможностей протокола Serial-ATA, которую на&nbsp;текующий момент поддерживают только SATA-диски от&nbsp;Hitachi, и&nbsp;которая <u>не поддерживается</u> Linux в&nbsp;настоящий момент. Будем ждать.<br /> Вывод 1: <strong>SCSI</strong> полезно и&nbsp;на серверах, и&nbsp;на рабочих станциях.</div><br /> <b>Удалено:</b><br /> <div class="deletions">Эта&nbsp;статья описывает какую пользу может принести пользователю использование SCSI-дисков, в&nbsp;том числе на&nbsp;рабочей станции.<br /> Во-первых SCSI-диски дороже. В&nbsp;несколько раз.<br /> Во-вторых максимальными размерами &mdash; SATA и&nbsp;IDE диски размером в&nbsp;250Gb встречаются весьма часто, и&nbsp;стоят вполне разумных денег. Стоимость SCSI-дисков размером в&nbsp;140G превышает тысячу долларов (1k$)!<br /> SCSI-диски продаются со&nbsp;скоростью вращения шпинделя в&nbsp;10'000 и&nbsp;15'000 оборотов в&nbsp;минуту. Против 7'200 максимальной скорости у&nbsp;IDE/SATA дисков (за исключением одного единственного HDD&nbsp;от&nbsp;Western Digital, который и&nbsp;стоит как&nbsp;SCSI, и&nbsp;объём имеет небольшой). Это&nbsp;первое преимущество. Собственно высокая цена и&nbsp;маленькие объёмы диктуются, видимо, в&nbsp;первую очередь этим.<br /> У&nbsp;SCSI есть ещё одно преимущество, выглядещее очень скромно, но&nbsp;делающее SCSI дисков единственным выбором в&nbsp;большинстве многопользовательских решений и&nbsp;серверов с&nbsp;большой нагрузкой &mdash; <u>очередь запросов</u>.<br /> SCSI-диск может получить несколько запросов, после чего выполнить их&nbsp;и передать результат хост-контроллеру в&nbsp;произвольном порядке. Что&nbsp;это означает на&nbsp;практике?<br /> В&nbsp;low-end серверах (к коим и&nbsp;относится подавляющее большинство серверов в&nbsp;xUSSR) на&nbsp;SCSI-дисках часто пытаются сэкономить. А&nbsp;зря. В&nbsp;большинстве задач, выполняемых этими самыми low-end серверами, ключевыми для&nbsp;производительности являются оперативная память (её количество) и&nbsp;дисковая подсистема, а&nbsp;процессор является предпоследним (перед видеокартой, разумеется).<br /> Например для&nbsp;корпоративного почтового сервера и&nbsp;intranet/internet сайта (а это&nbsp;одни из&nbsp;самых частых задач для&nbsp;low-end UNIX-серверов) обычно достаточно процессора Pentium III, но&nbsp;512Mb-1Gb памяти и&nbsp;маленький (<span class="nobr">9&ndash;18</span>Gb) &laquo;старенький&raquo; SCSI HDD&nbsp;может дать заметный прирост в&nbsp;производительности (на почтовом сервере провайдера или&nbsp;крупной компании это&nbsp;будет видно лучше всего).<br /> В&nbsp;многопользовательских системах, я&nbsp;надеюсь, преимущества SCSI уже&nbsp;очевидны.<br /> При&nbsp;такой сборке нагрузка на&nbsp;дисковую подсистему значительна, и&nbsp;использование SCSI-диска может ускорить сборку. Кроме того, при&nbsp;быстром процессоре (а уж&nbsp;тем более SMP&nbsp;машине с&nbsp;быстрыми процессорами) это&nbsp;может отразиться на&nbsp;общей &laquo;отзывчивости&raquo; системы.<br /> Факт 2: cvs&nbsp;update на&nbsp;большом дереве исходников процесс весьма долгий. На&nbsp;девелоперском сервере, которым я&nbsp;пользуюсь для&nbsp;разработки, установлен LSI-контроллер с&nbsp;64Mb кэша (с батарейкой) и&nbsp;RAID5 массив из&nbsp;15krpm 36Gb SCSI дисков. По&nbsp;сравнению с&nbsp;моей рабочей машиной cvs&nbsp;работает более чем&nbsp;на&nbsp;порядок быстрее. При&nbsp;том что&nbsp;линейная скорость чтения с&nbsp;дисков у&nbsp;моей рабочей машины выше (!).<br /> Ежеминутный поиск всех изменившихся файлов в&nbsp;/ ощутимо тормозит систему, если домашний каталог находится на&nbsp;IDE-диске. На&nbsp;SCSI-дисках это&nbsp;абсолютно незаметно. Копирование выполняется на&nbsp;SATA-диск размером 250G (он большой и&nbsp;относильно SCSI-дисков недорогой), а&nbsp;сам домашний каталог размещается, естественно, на&nbsp;SCSI-дисках.<br /> Оптимальная конфигурация для&nbsp;рабочей станции на&nbsp;сегодняшний день &mdash; маленький SCSI-диск (или RAID-массив, смотря по&nbsp;финансовым способностям) для&nbsp;основных рабочих документов и&nbsp;данных и&nbsp;один SATA-диск для&nbsp;мультимедиа-данных и&nbsp;прочих данных большого размера с&nbsp;преимущественно последовательным доступом.<br /> Я&nbsp;долго мечтал о&nbsp;низкооборотных HDD&nbsp;со&nbsp;SCSI-интерфейсом, и&nbsp;моя мечта почти сбылась. TCQ&nbsp;(Tagged Command Queue) является одной из&nbsp;возможностей протокола Serial-ATA, которую на&nbsp;текующий момент поддерживают только SATA-диски от&nbsp;Hitachi, и&nbsp;которая <u>не поддерживается</u> Linux в&nbsp;настоящий момент. Будем ждать.<br /> Вывод 1: SCSI полезно и&nbsp;на серверах, и&nbsp;на рабочих станциях.</div></div> http://freesource.info/wiki/ZachemNamSCSI/show?time=2004-11-10+18%3A54%3A59 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/ZachemNamSCSI&" class="">/Зачем&nbsp;Нам&nbsp;SCSI</a> за <a href="http://freesource.info/wiki/ZachemNamSCSI?time=2004-11-10+18%3A54%3A59">2004-11-10 18:54:59</a> и <a href="http://freesource.info/wiki/ZachemNamSCSI?time=2004-12-06+19%3A39%3A59">2004-12-06 19:39:59</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Эта&nbsp;статья описывает какую пользу может принести пользователю использование SCSI-дисков, в&nbsp;том числе на&nbsp;рабочей станции.<br /> Во-вторых максимальными размерами &mdash; SATA и&nbsp;IDE диски размером в&nbsp;250Gb встречаются весьма часто, и&nbsp;стоят вполне разумных денег. Стоимость SCSI-дисков размером в&nbsp;140G превышает тысячу долларов (1k$)!<br /> SCSI-диски продаются со&nbsp;скоростью вращения шпинделя в&nbsp;10'000 и&nbsp;15'000 оборотов в&nbsp;минуту. Против 7'200 максимальной скорости у&nbsp;IDE/SATA дисков (за исключением одного единственного HDD&nbsp;от&nbsp;Western Digital, который и&nbsp;стоит как&nbsp;SCSI, и&nbsp;объём имеет небольшой). Это&nbsp;первое преимущество. Собственно высокая цена и&nbsp;маленькие объёмы диктуются, видимо, в&nbsp;первую очередь этим.<br /> У&nbsp;SCSI есть ещё одно преимущество, выглядещее очень скромно, но&nbsp;делающее SCSI дисков единственным выбором в&nbsp;большинстве многопользовательских решений и&nbsp;серверов с&nbsp;большой нагрузкой &mdash; <u>очередь запросов</u>.<br /> SCSI-диск может получить несколько запросов, после чего выполнить их&nbsp;и передать результат хост-контроллеру в&nbsp;произвольном порядке. Что&nbsp;это означает на&nbsp;практике?<br /> 100 пользователей работают с&nbsp;базой данных. Каждый пользователь пытается считать свои данные. Данные пользователей, разумеется, разбросаны по&nbsp;поверхности дисков. Для&nbsp;современных дисков самое большое время &mdash; это&nbsp;время позиционирования головки, и&nbsp;для считывания 100 блоков данных в&nbsp;разных местах диска головка 100 раз&nbsp;будет перемещена в&nbsp;произвольное место диска. Именно когда несколько процессов одновременно работают с&nbsp;диском пользователь и&nbsp;слышит характерное &laquo;шуршание&raquo; диска, обычно сопровождающее ощутимые замедления работы компьютера при&nbsp;перегрузке диска операциями.<br /> SCSI-диск поступит умнее &mdash; он&nbsp;отсортирует эти&nbsp;100 запросов в&nbsp;том порядке, в&nbsp;котором _ему_ их&nbsp;удобнее обрабатывать (с учётом того, какие данные или&nbsp;часть их&nbsp;уже есть в&nbsp;кэше и&nbsp;где в&nbsp;настоящий момент находится головка диска) и&nbsp;сделает <u>один проход</u> по&nbsp;поверхности диска, вместо псевдослучайных &laquo;дёрганий&raquo; считывающей головкой у&nbsp;IDE-диска. Результат &mdash; при&nbsp;параллельном доступе к&nbsp;диску множеством процессов увеличение проихводительности в&nbsp;разы, а&nbsp;иногда на&nbsp;порядки.<br /> В&nbsp;low-end серверах (к коим и&nbsp;относится подавляющее большинство серверов в&nbsp;xUSSR) на&nbsp;SCSI-дисках часто пытаются сэкономить. А&nbsp;зря. В&nbsp;большинстве задач, выполняемых этими самыми low-end серверами, ключевыми для&nbsp;производительности являются оперативная память (её количество) и&nbsp;дисковая подсистема, а&nbsp;процессор является предпоследним (перед видеокартой, разумеется).<br /> Например для&nbsp;корпоративного почтового сервера и&nbsp;intranet/internet сайта (а это&nbsp;одни из&nbsp;самых частых задач для&nbsp;low-end UNIX-серверов) обычно достаточно процессора Pentium III, но&nbsp;512Mb-1Gb памяти и&nbsp;маленький (<span class="nobr">9&ndash;18</span>Gb) &laquo;старенький&raquo; SCSI HDD&nbsp;может дать заметный прирост в&nbsp;производительности (на почтовом сервере провайдера или&nbsp;крупной компании это&nbsp;будет видно лучше всего).<br /> Факт 1: параллельная сборка (make -j&lt;n&gt;) даже на&nbsp;однопроцессорных машинах даёт преимущество перед последовательной (это связано с&nbsp;тем, что&nbsp;пока один процесс читает данные с&nbsp;диска, другой может выполнять собственно обработку, то&nbsp;есть идёт равномерная загрузка и&nbsp;процессора и&nbsp;дисковой подсистемы). Оптимальное значение n, подобраное эмпирически, является &lt;количество процессорв&gt; * 4.<br /> При&nbsp;такой сборке нагрузка на&nbsp;дисковую подсистему значительна, и&nbsp;использование SCSI-диска может ускорить сборку. Кроме того, при&nbsp;быстром процессоре (а уж&nbsp;тем более SMP&nbsp;машине с&nbsp;быстрыми процессорами) это&nbsp;может отразиться на&nbsp;общей &laquo;отзывчивости&raquo; системы.<br /> Факт 2: cvs&nbsp;update на&nbsp;большом дереве исходников процесс весьма долгий. На&nbsp;девелоперском сервере, которым я&nbsp;пользуюсь для&nbsp;разработки, установлен LSI-контроллер с&nbsp;64Mb кэша (с батарейкой) и&nbsp;RAID5 массив из&nbsp;15krpm 36Gb SCSI дисков. По&nbsp;сравнению с&nbsp;моей рабочей машиной cvs&nbsp;работает более чем&nbsp;на&nbsp;порядок быстрее. При&nbsp;том что&nbsp;линейная скорость чтения с&nbsp;дисков у&nbsp;моей рабочей машины выше (!).<br /> Факт 3: у&nbsp;меня есть текущие данные, которые не&nbsp;удобно класть в&nbsp;cvs (постоянно перемещаются между каталогами, часто создаются новые и&nbsp;удаляются, и&nbsp;т.д). Например такими данными является почта.<br /> Я&nbsp;хочу иметь ежеминутные срезы группы рабочих каталогов за&nbsp;последний час, ежечасовые за&nbsp;последние пару дней, ежедневные за&nbsp;пару недель, еженедельные за&nbsp;пару месяцев, а&nbsp;также ежемесячные за&nbsp;несколько лет.<br /> Ежеминутный поиск всех изменившихся файлов в&nbsp;/ ощутимо тормозит систему, если домашний каталог находится на&nbsp;IDE-диске. На&nbsp;SCSI-дисках это&nbsp;абсолютно незаметно. Копирование выполняется на&nbsp;SATA-диск размером 250G (он большой и&nbsp;относильно SCSI-дисков недорогой), а&nbsp;сам домашний каталог размещается, естественно, на&nbsp;SCSI-дисках.<br /> Оптимальная конфигурация для&nbsp;рабочей станции на&nbsp;сегодняшний день &mdash; маленький SCSI-диск (или RAID-массив, смотря по&nbsp;финансовым способностям) для&nbsp;основных рабочих документов и&nbsp;данных и&nbsp;один SATA-диск для&nbsp;мультимедиа-данных и&nbsp;прочих данных большого размера с&nbsp;преимущественно последовательным доступом.<br /> Я&nbsp;долго мечтал о&nbsp;низкооборотных HDD&nbsp;со&nbsp;SCSI-интерфейсом, и&nbsp;моя мечта почти сбылась. TCQ&nbsp;(Tagged Command Queue) является одной из&nbsp;возможностей протокола Serial-ATA, которую на&nbsp;текующий момент поддерживают только SATA-диски от&nbsp;Hitachi, и&nbsp;которая <u>не поддерживается</u> Linux в&nbsp;настоящий момент. Будем ждать.<br /> Вывод 2: линейная скорость чтения далеко не&nbsp;самое важное, производительность дисковой подсистемы надо мерять специализироваными синтетическими тестами, такими как&nbsp;bonnie, или&nbsp;на&nbsp;реальных задачах.<br /> <!--notypo-->{{backlinks}}<!--/notypo--></div><br /> <b>Удалено:</b><br /> <div class="deletions">Эта&nbsp;статья описывает какую пользу может принести пользователю использование<br /> SCSI-дисков, в&nbsp;том числе на&nbsp;рабочей станции.<br /> Во-вторых максимальными размерами &mdash; SATA и&nbsp;IDE диски размером в&nbsp;250Gb<br /> встречаются весьма часто, и&nbsp;стоят вполне разумных денег. Стоимость SCSI-дисков<br /> размером в&nbsp;140G превышает тысячу долларов (1k$)!<br /> SCSI-диски продаются со&nbsp;скоростью вращения шпинделя в&nbsp;10'000 и&nbsp;15'000 оборотов<br /> в&nbsp;минуту. Против 7'200 максимальной скорости у&nbsp;IDE/SATA дисков (за исключением<br /> одного единственного HDD&nbsp;от&nbsp;Western Digital, который и&nbsp;стоит как&nbsp;SCSI, и&nbsp;объём<br /> имеет небольшой). Это&nbsp;первое преимущество. Собственно высокая цена и&nbsp;маленькие<br /> объёмы диктуются, видимо, в&nbsp;первую очередь этим.<br /> У&nbsp;SCSI есть ещё одно преимущество, выглядещее очень скромно, но&nbsp;делающее SCSI<br /> дисков единственным выбором в&nbsp;большинстве многопользовательских решений и<br /> серверов с&nbsp;большой нагрузкой &mdash; <u>очередь запросов</u>.<br /> SCSI-диск может получить несколько запросов, после чего выполнить их&nbsp;и передать<br /> результат хост-контроллеру в&nbsp;произвольном порядке. Что&nbsp;это означает на&nbsp;практике?<br /> 100 пользователей работают с&nbsp;базой данных. Каждый пользователь пытается считать<br /> свои данные. Данные пользователей, разумеется, разбросаны по&nbsp;поверхности дисков.<br /> Для&nbsp;современных дисков самое большое время &mdash; это&nbsp;время позиционирования головки,<br /> и&nbsp;для считывания 100 блоков данных в&nbsp;разных местах диска головка 100 раз&nbsp;будет<br /> перемещена в&nbsp;произвольное место диска. Именно когда несколько процессов одновременно<br /> работают с&nbsp;диском пользователь и&nbsp;слышит характерное &laquo;шуршание&raquo; диска, обычно<br /> сопровождающее ощутимые замедления работы компьютера при&nbsp;перегрузке диска<br /> операциями.<br /> SCSI-диск поступит умнее &mdash; он&nbsp;отсортирует эти&nbsp;100 запросов в&nbsp;том порядке,<br /> в&nbsp;котором _ему_ их&nbsp;удобнее обрабатывать (с учётом того, какие данные или&nbsp;часть<br /> их&nbsp;уже есть в&nbsp;кэше и&nbsp;где в&nbsp;настоящий момент находится головка диска) и&nbsp;сделает<br /> <u>один проход</u> по&nbsp;поверхности диска, вместо псевдослучайных &laquo;дёрганий&raquo;<br /> считывающей головкой у&nbsp;IDE-диска. Результат &mdash; при&nbsp;параллельном доступе к<br /> диску множеством процессов увеличение проихводительности в&nbsp;разы, а&nbsp;иногда на<br /> порядки.<br /> В&nbsp;low-end серверах (к коим и&nbsp;относится подавляющее большинство серверов в<br /> xUSSR) на&nbsp;SCSI-дисках часто пытаются сэкономить. А&nbsp;зря. В&nbsp;большинстве задач,<br /> выполняемых этими самыми low-end серверами, ключевыми для&nbsp;производительности<br /> являются оперативная память (её количество) и&nbsp;дисковая подсистема, а&nbsp;процессор<br /> является предпоследним (перед видеокартой, разумеется).<br /> Например для&nbsp;корпоративного почтового сервера и&nbsp;intranet/internet сайта<br /> (а это&nbsp;одни из&nbsp;самых частых задач для&nbsp;low-end UNIX-серверов) обычно достаточно<br /> процессора Pentium III, но&nbsp;512Mb-1Gb памяти и&nbsp;маленький (<span class="nobr">9&ndash;18</span>Gb) &laquo;старенький&raquo;<br /> SCSI HDD&nbsp;может дать заметный прирост в&nbsp;производительности (на почтовом сервере<br /> провайдера или&nbsp;крупной компании это&nbsp;будет видно лучше всего).<br /> Факт 1: параллельная сборка (make -j&lt;n&gt;) даже на&nbsp;однопроцессорных машинах даёт<br /> преимущество перед последовательной (это связано с&nbsp;тем, что&nbsp;пока один процесс<br /> читает данные с&nbsp;диска, другой может выполнять собственно обработку, то&nbsp;есть<br /> идёт равномерная загрузка и&nbsp;процессора и&nbsp;дисковой подсистемы). Оптимальное<br /> значение n, подобраное эмпирически, является &lt;количество процессорв&gt; * 4.<br /> При&nbsp;такой сборке нагрузка на&nbsp;дисковую подсистему значительна, и&nbsp;использование<br /> SCSI-диска может ускорить сборку. Кроме того, при&nbsp;быстром процессоре (а уж<br /> тем&nbsp;более SMP&nbsp;машине с&nbsp;быстрыми процессорами) это&nbsp;может отразиться на&nbsp;общей<br /> &laquo;отзывчивости&raquo; системы.<br /> Факт 2: cvs&nbsp;update на&nbsp;большом дереве исходников процесс весьма долгий.<br /> На&nbsp;девелоперском сервере, которым я&nbsp;пользуюсь для&nbsp;разработки, установлен<br /> LSI-контроллер с&nbsp;64Mb кэша (с батарейкой) и&nbsp;RAID5 массив из&nbsp;15krpm 36Gb SCSI<br /> дисков. По&nbsp;сравнению с&nbsp;моей рабочей машиной cvs&nbsp;работает более чем&nbsp;на&nbsp;порядок<br /> быстрее. При&nbsp;том что&nbsp;линейная скорость чтения с&nbsp;дисков у&nbsp;моей рабочей машины<br /> выше (!).<br /> Факт 3: у&nbsp;меня есть текущие данные, которые не&nbsp;удобно класть в&nbsp;cvs (постоянно<br /> перемещаются между каталогами, часто создаются новые и&nbsp;удаляются, и&nbsp;т.д).<br /> Например такими данными является почта.<br /> Я&nbsp;хочу иметь ежеминутные срезы группы рабочих каталогов за&nbsp;последний час,<br /> ежечасовые за&nbsp;последние пару дней, ежедневные за&nbsp;пару недель, еженедельные<br /> за&nbsp;пару месяцев, а&nbsp;также ежемесячные за&nbsp;несколько лет.<br /> Ежеминутный поиск всех изменившихся файлов в&nbsp;/ ощутимо тормозит систему,<br /> если домашний каталог находится на&nbsp;IDE-диске. На&nbsp;SCSI-дисках это&nbsp;абсолютно<br /> незаметно. Копирование выполняется на&nbsp;SATA-диск размером 250G (он большой<br /> и&nbsp;относильно SCSI-дисков недорогой), а&nbsp;сам домашний каталог размещается,<br /> естественно, на&nbsp;SCSI-дисках.<br /> Оптимальная конфигурация для&nbsp;рабочей станции на&nbsp;сегодняшний день &mdash; маленький<br /> SCSI-диск (или RAID-массив, смотря по&nbsp;финансовым способностям) для&nbsp;основных<br /> рабочих документов и&nbsp;данных и&nbsp;один SATA-диск для&nbsp;мультимедиа-данных и&nbsp;прочих<br /> данных большого размера с&nbsp;преимущественно последовательным доступом.<br /> Я&nbsp;долго мечтал о&nbsp;низкооборотных HDD&nbsp;со&nbsp;SCSI-интерфейсом, и&nbsp;моя мечта почти<br /> сбылась. TCQ&nbsp;(Tagged Command Queue) является одной из&nbsp;возможностей протокола<br /> Serial-ATA, которую на&nbsp;текующий момент поддерживают только SATA-диски от<br /> Hitachi, и&nbsp;которая <u>не поддерживается</u> Linux в&nbsp;настоящий момент. Будем ждать.<br /> Вывод 2: линейная скорость чтения далеко не&nbsp;самое важное, производительность<br /> дисковой подсистемы надо мерять специализироваными синтетическими тестами,<br /> такими как&nbsp;bonnie, или&nbsp;на&nbsp;реальных задачах.</div></div>