Pull to refresh

Comments 15

Мне вот кажется, что это позиционирование — «для видеонаблюдения» — только отпугнёт рядового обывателя. Он будет долго стоять и сомневаться, а заработает ли этот винт в его компьютере, а плохо это или хорошо, что он «для видеонаблюдения», а ну его, куплю-ка я другой…
Нужно чётко пояснять, что любой жёсткий диск будет работать там-то и там-то, а отличия заключаются в том-то и том-то и несоблюдение рекомендаций ничем не грозит (или грозит тем-то и тем-то).
Мне вот кажется, что это позиционирование — «для видеонаблюдения» — только отпугнёт рядового обывателя. Он будет долго стоять и сомневаться, а заработает ли этот винт в его компьютере, а плохо это или хорошо, что он «для видеонаблюдения», а ну его, куплю-ка я другой…

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

работать будет, но у производителя есть изделия, которые лучше подойдут для той или иной роли. На примере одного из семейств WD как-то показывал, что из одной аппаратной платформы получают накопители для разных задач посредством конфигурирования микропрограммы.

Выбирая диск лучше прислушиваться к рекомендациям производителя.
У тошибы очень уникальный алгоритм работы кеша.
Вот ни у кого такого нет — только у тошибы.
В микрокод сохраняет данные к которым недавно обращались, и на этом всё.
Нет предупредительного чтения: если нужно прочитать один единственный сектор — будет прочитан один сектор. О том что можно прочитать все сектора на этой позиции головок (диск-то вращается) — умная электроника не догадывается.
Нет отложенной записи — запись одного блока здесь и сейчас. Следом идёт такой-же мелкий блок на запись сразу после первого — нет, надо дождаться пока запишется первый.

Про видеонаблюдение они не зря написали — с большими блоками эти диски работают замечательно. А вот с мелкими — хуже старой флеш карты.
Нет предупредительного чтения: если нужно прочитать один единственный сектор — будет прочитан один сектор. О том что можно прочитать все сектора на этой позиции головок (диск-то вращается) — умная электроника не догадывается.

Отключение различных read look ahead в различных накопителях приводит к скоростям при которых пропускная способность PIO-0 кажется вполне уместной. Если дизассемблировать микропрограмму тошибы то полагаю там тоже увидим свои алгоритмы упреждающего чтения. На примере других семейств можно сказать, что при чтении в обычном режиме и натыкании на дефекты мы получим огромные паузы, которые намного больше, чем попытка чтения одиночного дефекта (даже с учетом обновления SMART, попытки переназначения и т.п.), что явно намекает на наличие упреждающего чтения. Как и факт достижения высокой линейной скорости чтения.
Про видеонаблюдение они не зря написали — с большими блоками эти диски работают замечательно. А вот с мелкими — хуже старой флеш карты.

по большому счету все жесткие диски при записи мелких блоков в разные места будут показывать провальную производительность. И если начать смотреть в цифрах именно похожие диски у разных производителей, то отличия вроде бы и можно увидеть, но назвать их существенными, которые в повседневной жизни будут заметны на глаз, мы вряд ли сможем. Кроме этого у чрезмерной буферизации и всякой самодеятельности с отложенными записями есть обратная сторона медали. В случае аварийного отключения питания может так оказаться, что слишком много данных оказались недописанными и получим более масштабные потери.
по большому счету все жесткие диски при записи мелких блоков в разные места будут показывать провальную производительность.

Все диски читают мелкие файлы медленно, но провал именно у тошибы.

Кстати, чистокровный хитачи имел отложенное чтение и запись с сортировкой на удалённость перемещения механики и размер блока данных. Революционный алгоритм для своего времени. Чтобы сейчас этот код работал сто-же эффективно — размер кеша нужно увеличить пропорционально объёму диска. А там уже проблема с самой памятью всплывает — не хватает пропускной способности рандомного чтения.
Все диски читают мелкие файлы медленно, но провал именно у тошибы.

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

Услышав ваше заявление, я решил проверить, есть ли основания упрекнуть все виды дисков Toshiba в чрезмерной медлительности. Для этого я взял два 2,5" накопителя: Toshiba MQ01ABD075 и Hitachi HTS541075A7E630. Накопители емкостью по 750гб, имеют по 2 пластины и по три головки. Плотность записи сопоставима. Один 2013 года выпуска, второй 2014. Диски совершенно исправны и нигде оффлайн скан не вносит лепту в тестирование. Взяты относительно старые диски, чтобы в результаты тестирования не вмешивались хитрости современных SMR дисков, которые в штатных условиях в тестовом ПО покажут более красивые значения, но это не будет справедливым результатом. Создаем по одному разделу на всю емкость на каждом диске и запускаем CrystalDiskMark


результат тестирования Toshiba MQ01ABD075


результат тестирования Hitachi HTS541075A7E630

Можете видеть сами, что результаты тестирования похожих дисков дают похожие результаты (отклонения в пределах 10%). Причем на других экземплярах этих же семейств отклонения с небольшой погрешностью могут отличаться, так как плотность зон у каждого накопителя будет разной.
Красивые графики, но я говорил о другом режиме чтения/записи. Когда данные находятся в одном секторе, то-есть перемещения механики не требуется. Тот самый момент, когда данные поступили/запросились для одной позиции механики, но в хаотичном порядке.
У тошибы кеш работает как классический FIFO, у хитачи работает сортировка. В результате тошиба пережевывает одну позицию очень долго, а хитачи за один оборот шпинделя.

Работа мелкими файлами: 99,9% из них были залиты на пустое место, в линейном режиме. И точно так-же читаются. Большинство из них меньше четырёх килобайт, и таких — гигабайты. Разницу в скорости — можно одной сигаретой измерить.
Так может измерьте? Покажите практический пример при котором в схожих по характеристикам накопителями разных производителей будет заметно существенное превосходство идеологии работы микропрограммы. Потому как в обычных задачах копирования большого количества файлов разного размера (около 250 000 суммарным объемом 100Гб с SSD), мне не удалось увидеть заметной разницы.

Кстати, хотелось бы уточнить, а на основании чего вы вообще рассказываете об идеологии работы микропрограммы какого-либо из накопителей? Из какого источника взята информация? Если это самостоятельная работа с дизассемблированной фирмварью, то можно бы было показать немножечко скринщотов из IDA?
На основании замера секундомером первой пересборки жирного проекта, до момента — когда файлы проекта попадают в кеш системы. Разница во времени сборки двукратная.
Этого достаточно для написания гневного отзыва о продукте, но явно не хватает для запуска декомпилятора. В любом случае сейчас проще купить диск другой марки, чем дорабатывать напильником имеющийся.
А можно ли конкретно указать какая именно модель вызвала ваше неудовольствие и какая именно модель порадовала. Есть подозрение, что вы сравнили слишком разные диски. Потому как в повседневное работе в которой хватает рутины в виде копирования большого количества файлов разного размера, я не могу выделить какого-либо из производителей, как конкретного аутсайдера. Скорее наоборот подмечаю, что продукты разных производителей с примерно одинаковой плотностью записи и скоростью вращения вала показывают схожие результаты.
все жесткие диски при записи мелких блоков в разные места будут показывать провальную производительность.

Кроме SMR дисков (device managed) — 4K random transfers ...Seagate Archive recorded 0.30MB/s and 10.52MB/s for reads and writes respectively.… 2693 IOPS write. — https://www.storagereview.com/node/4665
Естественно за счет склеивания множества мелких записей в разные места в небольшое количество крупных записей и дополнительную трансляцию адресов.

SMR диски это отдельный разговор. Ловкие манипуляции с медиакешем помогут показать красивые цифры в тестировании, особенно с небольшими объемами данных. Но куда интереснее будут показатели скорости при работе с данными, которых нет в медиакеше. Могу сказать сразу, что эти показатели неприятно удивят (значения будут намного хуже, чем у обычных дисков).
Любопытно, что такое «одновременная запись 32 видеопотоков до 4 Мбит/c каждый»
32*4=128Мбит/с или 16мб/с. Какая-то детская скорость, 100мб/с на запись умели десктопные харды уже 10 лет назад. В конце диска скорость проседала, но не настолько.
Ещё можно предположить, что пишущий софт решил избавиться от файловой системы и писать данные напрямую по адресам секторов. Для этого общее количество секторов поделил на количество камер, и выделил условные 32 раздела диска, и теперь при записи каждого блока всех камер за период времени головка делает N раз позиционирование. И производитель гарантирует, что диск успеет все записать в таком режиме. Но ведь так, я надеюсь, никто не делает. Обычно все же пишут единым блоком, который уже содержит сегменты от каждого видеопотока, или сбрасывают буфер по очередно от каждой камеры.
Подумалось, что надо попробовать написать программу, которая будет писать именно так данные, и проверить на обычных дисках. Замерить скорость записи по 32 разным распределённым секторам, и какая зависимость от размера блока.
32*4=128Мбит/с или 16мб/с. Какая-то детская скорость, 100мб/с на запись умели десктопные харды уже 10 лет назад. В конце диска скорость проседала, но не настолько.
Линейная запись и запись в 32 разных места — это две большие разницы. Во втором случае огромные затраты времени на позиционирование.
Ещё можно предположить, что пишущий софт решил избавиться от файловой системы и писать данные напрямую по адресам секторов. Для этого общее количество секторов поделил на количество камер, и выделил условные 32 раздела диска, и теперь при записи каждого блока всех камер за период времени головка делает N раз позиционирование. И производитель гарантирует, что диск успеет все записать в таком режиме.

В таком режиме вряд-ли успеет, ибо затраты времени на позиционирование будут катастрофически велики.Проблему решить можно только приличной буферизацией, чтобы писать относительно крупными порциями по каждому из потоков и уменьшить количество перемещений головок.
Кстати пишущий софт многих видеорегистраторов использует проприетарные файловые системы. Например такие как WFS В которых все описание объектов сводится к описанию цепочки блоков, дате, времени и номере камеры.
Но ведь так, я надеюсь, никто не делает. Обычно все же пишут единым блоком, который уже содержит сегменты от каждого видеопотока, или сбрасывают буфер по очередно от каждой камеры.

обычно сброс потока привязан еще и ко времени. в случае камер с малым битрейтом будет слишком редкий сброс и как следствие в случае аварий может не успеть быть сброшено нужное. Поэтом блоки могут заполняться частями, что в итоге увеличивает нагрузку в виде перемещений БМГ. На примере с WFS0.4 достаточно хорошо можно понять какую нагрузку на диск дает запись в несколько потоков.
Также японская компания заявила об ориентации на корпоративный сегмент с 2020 года

Вполне логично так как пользователи стараются покупать технику для дома с SSD и старым HDD тяжело конкурировать
Sign up to leave a comment.