Имеет ли значение размер кеша жесткого диска в RAID?

10790
Andrew

Возможное дублирование: имеет
ли значение размер буфера жесткого диска?

Итак, не совсем RAID, но я только что купил Drobo без дисковода, чтобы использовать его в качестве необработанного хранилища для работы с видео / фотографиями, и сейчас просматриваю жесткие диски, чтобы вставить в него. В большинстве случаев существует довольно большая разница в цене между дисками с размером кэш-памяти 16 МБ / 32 МБ / 64 МБ. В моем конкретном случае, с 4 дисками по 1 ТБ в Drobo, размер кеша каким-либо образом увеличивает производительность? Заранее спасибо!

4
Если вы отражаете, то да. Если он будет удален ... он будет бесполезен ... тогда обычно используются выделенные рейд-карты с кешем ... так как 1 диск не может кешировать частичный файл ... но 1 рейд карта может кешировать, на каких дисках лежат все файлы .. вы увидеть. ppumkin 12 лет назад 0
@ppumkin, если он чередующийся, то оба диска содержат часть данных и, следовательно, каждую часть кэша. psusi 12 лет назад 3

2 ответа на вопрос

5
Ethabelle

Кэширование позволяет повысить скорость обработки, однако уведомление о производительности может быть минимальным для той цели, для которой вы его используете (хранилище). Диски RAID будут использовать свой полный кеш.

Изменить: просто, чтобы объяснить немного больше о том, что такое кэширование; он хранит данные, чтобы будущие запросы могли обслуживаться быстрее. Это означает, что чем выше кэш, тем больше блоков данных может быть сохранено, что означает, что их можно будет извлечь быстрее.

Спасибо большое! Я не пытаюсь быть дешевым с жесткими дисками, особенно когда они выполняют важную работу, мне просто нужно было убедиться, что я покупаю правильные инструменты для этой работы. Еще раз спасибо. Andrew 12 лет назад 0
Понятный! Я бы сказал, если нет большой разницы в цене, используйте более высокий кеш, но если есть (а иногда и есть), я бы не стал беспокоиться. Вы не заметите большой разницы в скорости, если будете использовать ее как хранилище. Ethabelle 12 лет назад 2
1
psusi

Размер кэша жесткого диска никуда не имеет значения, так как все современные операционные системы выполняют свое собственное кэширование и имеют НАМНОГО больше памяти, чтобы использовать его. Если к нему недавно обращались, то он все равно будет находиться в кеше ОС, так что наличие его в кеше диска не имеет значения, так как ОС больше не будет запрашивать у диска эти данные.

По сравнению с кэшем ЦП это похоже на то, как ваш современный толстый кэш L3 объемом 8 МБ имеет современный процессор, а затем просматривает годы и находит процессоры с 128 МБ кэш-памяти L2, которые в 32 раза быстрее, но все еще имеют старые, медленные 8 МБ L3 кэш. Это не принесет пользы, так как сначала обращаются к L2, он больше и быстрее. В этот момент спор о том, должен ли кэш L3 иметь размер 8 или 16 МБ, является спорным вопросом, поскольку что-либо в L3 также будет в L2, поэтому L3 даже не увидит запрос.

Чтобы увидеть кеш диска и ядра в действии, вы можете поэкспериментировать с ddтем, насколько быстро вы можете читать с диска.

sudo dd if=/dev/sda of=/dev/null bs=52488 count=1 

Это будет читать 512 КБ с диска. Повторите это несколько раз, и вы увидите очень быстрые цифры. На этой старой машине у меня удобно, я вижу порядка 751 МБ / с. То есть с кешем ядра. Теперь, если вы добавите опцию iflag = direct, это отключит кеш ядра, что позволит вам измерить скорость кеша диска. Повторяя это, я вижу только около 100 МБ / с, что примерно соответствует максимальной скорости передачи этого старого интерфейса IDE. Это не намного лучше, чем небуферизованная пропускная способность диска около 61 МБ / с.

Теперь спросите себя, что хорошего в том, что делает медленный, меньший кеш накопителя, когда вы не обходите кеш ядра.

-1. Кэширование жесткого диска все еще используется и будет использоваться годами. Операционная система использует тот кэш памяти, о котором вы говорите, в первую очередь для системных данных и файлов. Эндрю будет использовать несколько жестких дисков, поэтому изменение в том, что данные находятся в этой кэш-памяти, еще больше уменьшается. Похоже, что Эндрю будет использовать систему для редактирования фото / видео, а не для хранения. Это на самом деле означает, что много ввода-вывода и кеша помогут. Например, кеш будет служить буфером для записи, так что приложение Эндрю сможет продолжать работу, пока жесткий диск записывает данные из кеша на жесткие диски. Amadeusz Wieczorek 12 лет назад 3
@Amadeu, используется ли он или нет, не имеет никакого отношения к тому, имеет ли это значение. Смотрите подробное объяснение в Википедии, на которое ссылается другой вопрос, который упоминал Дейв М. Операционная система использует свой собственный кэш для буферизации ввода-вывода, чтобы приложение могло продолжать работать, поэтому нет необходимости и никакой выгоды иметь больше кэша на дисках. psusi 12 лет назад 1
Есть чертовски веская причина для кэша на дисках, путь к диску быстрее, чем запись на диски. если вы сможете получить больше данных в накопитель, без того, чтобы эти данные фактически записывались в то время, то это ускорит передачу всех видов. не только это, но и большинство накопителей реализовали опережающее чтение, будь то обязательное для чтения, которое вы делаете или нет, перемещение этого или чего-либо в кэш на жестком диске, делает его перенос МНОГО быстрее, чем считывание с пластин, или снова выключить, в ситуации кеширования перечитывает. Psycogeek 12 лет назад 0
@Psycogeek, ему нужно всего лишь несколько секторов для обработки несоответствия скорости передачи интерфейса. Опять же, упреждающее чтение выполняется операционной системой, поэтому привод, выполняющий это также (по крайней мере, за одним или двумя секторами, который необходим только на старых интерфейсах IDE, не поддерживающих NCQ), не принесет пользы. Что касается перечитывания, я повторю еще раз: ОС уже хранит данные в гораздо большем кеше, поэтому больше не будет их читать. Вам также следует прочитать статью, на которую ссылается другой вопрос: http://www.pcguide.com/ref/hdd/perf/perf/spec/otherCache-c.html. psusi 12 лет назад 1
лучший способ сказать, выключите его :-) Я бы согласился, что разница в размерах не имеет такого большого значения, но тогда я хочу размер 1-4GIG, ооо, что я знаю. Для любого, кто может предположить, что он может сделать LOL 100% -ной разницы, это будет в каком-то бесполезном тесте. «Они относятся только к небольшой сумме переводов», да, зависимые. Что касается отдельного аппаратного обеспечения, выполняющего всю работу, то я за него, много-много дисков с кешами leetel меня вполне устраивают. Psycogeek 12 лет назад 0
@Psycogeek, вы не можете отключить кеш диска, но вместо этого вы можете отключить ядро ​​и сравнить разницу. Добавлен пример для ответа. psusi 12 лет назад 1
А с другой стороны, разве это не похоже на дебаты по кешу данных, даже если они нужны на процессоре? Ну и дела, память прямо здесь, и все, что в нем будет в следующем. НЕТ, потому что более короткий и быстрый путь - вот почему они делают это с самого начала. , , Даже если в системном кеше есть все это, передача из / в систему и дисковый кеш быстрее, передача из / в диски не такая быстрая. В какой момент он больше не нужен, в какой-то момент он недостаточно велик :-), но каждый кусочек помогает. Мы использовали диски назад, когда у них было «несколько секторов» кеша, а не возвращались. Psycogeek 12 лет назад 0
@Psycogeek, нет, это не так. Вопрос не в том, кешировать или нет, вопрос в том, был ли меньший, более медленный кеш на диске устаревшим из-за большего и более быстрого кеша в ОС. Неважно, насколько быстрая или медленная передача диска, когда вы никогда не выполняете эту передачу в первую очередь (потому что запрос удовлетворяется кешем ОС). psusi 12 лет назад 2
Он немного староват, но в этом документе делается вывод о том, что увеличение размера кэша на диске свыше 512 КБ имеет мало преимуществ при условии разумного кэша ОС. Чжу, Инву и Иминь Ху. «Дисковые встроенные кеши: оценка производительности системы». Моделирование, анализ и моделирование компьютерных телекоммуникационных систем, 2003. MASCOTS 2003. 11-й Международный симпозиум IEEE / ACM. IEEE, 2003. Adam Crume 11 лет назад 2