Если предлагать машинку для протягивания троса, то необходимо исходить из:
1. массы троса.
2. массы кабеля
3. учесть трение и того и другого о стенки трубы
4. учесть особенности сцепления колес со стенками трубы
и на фоне этих данных кажущаяся простой инженерная задачка перестает такой быть.
Версий несколько. Необходимы проверки.
1. Ошибки в драйвере ОС. Некорректно разбирается регистр ошибок и в некоторых случаях забирается содержимое пустого буфера. Отсюда гладкий скан, но прочитанное в некоторых точках не соответствует записанному.
2. Ошибки в микропрограмме жесткого диска.
Для исследования ошибок желательно сделать множественные попытки записи и чтения с сохранением результата чтения в файлы. После исследовать разночтения между тем что прочиталось в разных версиях и тем, что должно было быть записано.
То есть вопрос почему из-за озу могут гарантировано случаются ошибки чтения при работе с конкретными секторами.
Это ошибки чтения не из-за ОЗУ. Ошибки в ОЗУ зачастую никак не регистрируются, если не проводить дополнительный контроль целостности данных, как например это делали вы, и носят случайный характер. А вот ошибки в виде некорректного ремапа, когда точечно накопитель может быстро выдавать ABR при попытке чтения или устанавливать иные биты в регистре флагов и эти ошибки не регистрируются драйвером работающим с устройством могут приводить к ситуации описанной вами.
В принципе лучше и продолжать использовать специализированное ПО для тестирования и обслуживания дисков. Можно существенно сэкономить время и не потерять в качестве процедуры. Стоит лишь рассмотреть идеологию тестирования.
Автору удалось решить задачку подручными средствами. Правда туда были привнесены существенные тормоза в виде проверки прочитанного содержимого. Но в любом его стараниями был достигнут результат.
1. Все данные пишутся в зашумленном виде, а не в чистом, как представляется автору. При записи пользовательских данных нет разницы будут там нули или случайный паттерн. Это действие даст одинаковый результат в плане дальнейшего качества чтения.
2. У микропрограмм жестких дисков достаточно серьезные методы контроля целостности прочитанных данных. При некорректируемых за счет ECC ошибках чтения при стандартных АТА командах современный накопитель не отдаст никаких данных, а только сигнализирует об ошибке в регистре ошибок.
3. Искажение данных может происходить в ОЗУ накопителя при условии ее неисправности.
записываем диск случайным паттерном с чтением только что записанного блока и сравнением его чек-суммы;
читаем диск после полной записи, проверяя чек-суммы каждого блока;
Если есть желание проверить контроллер на предмет исправности его буферного ОЗУ, то в той же Victoria можно выполнить тест записи с DDD. В случае появления читабельных секторов с искаженным содержимым можно будет сделать вывод о необходимости замены PCB с переносом ПЗУ. Этот тест будет работать заметно быстрее варианта предложенного автором. В остальном все сведется к количеству циклов записи-чтения с переназначением (Remap). Если накопитель не совсем труп, то этими стараниями можно будет получить что-то хоть частично годное к эксплуатации. Если же проблема серьезна, то все эти действия приведут к запиливанию пластин.
Поэтому отбраковка логических частей диска тоже имеет смысл.
Попытки заочной отбраковки однозначно не имеют смысла в силу того, что не стоит гадать, где именно находятся проблемы. Необходимо проводить нормальное тестирование диска. И на основании тестов делать вывод о том стоит ли далее этот диск пытаться обслуживать или сразу отправить в утиль.
области MFT, которые как правило расположены в начале
MFT может быть фрагментирована и ее куски могут быть разбросаны по всему диску.
и в середине (резервная MFT) логической части диска.
MFT mirror — это всего лишь 4 записи (при стандартном размере записи 1024 байта — это 4кб). Также некоторые дисковые менеджеры ставят позицией MFT Mirr второй кластер.
По всему диску хаотично разбросаны индексные записи, в некоторых из них частота перезаписей была очень высокая и вероятность возникновения проблемы не ниже, чем в местах расположения MFT.
Пример разброса индексов по диску. обратите внимание на размер ползунка и его позицию.
Пример: диск обычного пользователя.
Таблица разделов.
Построим карту расположения фрагментов MFT
Результат построения.
предсказуемым оказался только первый фрагмент, который не самый крупный.
Если Hitachi (HGST), то там чередование небольшими зонами как у Seagate в примере выше. Но порядок чередования зон у накопителя с 2 пластинами и 4 головками будет таким 0,1,2,3,0,1,2,3 а не 0,1,2,3,3,2,1,0 как у Seagate.
Если после стольких прогонов, в том числе по проблемным секторам, он вышел в стабильную работу, то можно условно считать что запилов, приводящих к таким результатам, нету.
повреждения полимерного покрытия могут иметь место, но проход головок над ними пока что не приводит к новым контактам слайдера и поверхности. Но это событие носит вероятностный характер.
а поврежденнй цепляю на пару часов к машине на холостой ход. Головки в таком случае на парковке, а весь мусор, образовавшийся при запиле и летающий внутри диска должен осесть на специальных подушечках фильтрации.
есть нюанс. если диск уже обнаружил дефекты, то немалая вероятность, что просто так держать головки на парковке он не будет. А будут весьма активно работать процедуры оффлайн скана (не во всех семействах).
Тоже использую диск, выдающий ошибки чтения ближе к краям физических дисков (внутри коробки два диска).
Решение: разбит на два логических диска C: и D:, совпадающих с физическими, но последние 1 ГБ каждого физического диска не используются разделами (свободны). Уже четыре года никаких ошибок нет.
Вы заблуждаетесь. Вы не можете создать раздел только в границах одной физической пластины. Логическое пространство реализуется из зон чередующихся между всеми головками. Например реализация логического пространства в жестком диске Seagate ST9500325AS. На скриншоте можно увидеть, как идет чередование мини-зон.
Чередование зон в жестком диске Samsung HD753LJ
По моему опыту пластины ЖД редко умирают целиком и все сразу. Обычно портится только часть. Как правильно, центр или край.
Умирает там, где произойдет контакт слайдера и поверхности и появится первичное повреждение полимерного покрытия. Если повреждение полимера серьезно, то как бы вы не пытались создать разделы не затрагивающие места дефектов, то все ваши старания все равно будут насмарку по причине того, что проблему усугубят процедуры оффлайн сканирования.
Непонятно. Если диск выпал из массива незадолго перед крушением, то как определить какой именно, если метаданные в конце диска стёрты клиентом?
анализ метаданных файловых систем позволяет установить набор актуальных дисков в 99% случаев. Если расхождение между отвалами дисков совсем малозначимое, то необходимо анализировать содержимое последних файлов.
С помощью профессиональных инструментов, таких как Raid Explorer или PC3000Dataextractor RAID edition можно собирать разные варианты массива виртуально (поочередно исключая разные диски и каждый раз вести комплекс анализов). В случае серьезных расхождений данных не особо сложно определить неактуальный диск даже в обычном HEX редакторе.
Разумеется для этого необходимо знать устройство файловых систем и устройство различных типов файлов.
В случае VMFS при малой разнице по времени исключения дисков из массива можно и не определить тот, который нужно исключить при анализе метаданных VMFS. В таком случае необходимо анализировать файловые системы и данные в виртуальных машинах.
Думаю, этот процесс совмещён с борьбой против неравномерного износа памяти. Т.е. контроллер периодически тасует данные, чтобы не допустимть ситуации, когда, упрощённо говоря, где-то в одном месте протрётся «дырка», после чего весь накопитель можно будет выкинуть.
В гонке за производительность и за сохранение ресурса, микропрограммы NAND накопителей не увлекаются перезаписями статичных данных к которым нет никаких обращений. Они лежат мертвым грузом и блоки занимаемые ими не участвуют в ротации.
В итоге в DR лабораториях частые гости SSD которые были заполнены большим количеством статичных данных и в активной ротации блоков принимало участие слишком малое число блоков отчего и возник износ отдельных областей NAND памяти.
Кроме этого в АТА стандарте как-то не особо предусмотрена коммуникация ОС и SSD на предмет того, что грядет в ОС (например планируемое отключение). В связи с чем самовольные перезаписи в неудачные моменты — это дополнительные риски отказа устройства, которые заметно выше рисков получения нечитаемых данных из-за утечек зарядов.
Контроллеру, чтобы записать 1 изменённый кластер приходится вначале считать всю аппаратную страницу NAND (которая может достигать сотен килобайт в размере), изменить 4КБ, а потом всю её записать. Если размер страницы NAND составляет 64КБ, то мы имеем усиление записи в 16 раз.
Контроллер как правило оперирует блоками, которые в свою очередь состоят из группы NAND страниц (64,128 и т.п.). Размеры страниц в NAND микросхемах обычно все же не сотни килобайт, а 528, 2112, 4224, 4320, 8576, 8640, 8832, 8896, 9216, 17664, 18048, 18336 и др. Малые размеры справедливы для старых SLC микросхем, для современных TLC размеры поболее. Такие странные размеры потому, что кроме пользовательских данных необходимо хранить служебные данные (ECC, флаги, номера блоков, счетчики записей и т. п.).
Для того, чтобы SSD не превращался в коматозника при записи мелких объектов применяется буферизация, а также вводится понятие блок-апдейтов. Это блоки в которых записываются отдельные страницы для разных блоков, которые точечно накладываются на транслируемое логическое пространство.
Например при восстановлении данных, когда нет возможности оперировать штатными структурами транслятора обычно необходимо проводить поблочную сборку и находить отдельные блок-апдейты и накладывать их данные отдельными страничками поверх собираемого поблочно для получения актуальных данных.
Если производитель догадался сделать первые несколько ГБ диска (где находится битовая карта диска, FAT и прочие метаданные) работающими в режиме SLC (или кеширует их в буфере RAM),
принцип работы таков: любой физический блок в логическом банке, может выполнить любую роль в реализуемым этим банком логическом пространстве. Посему нет отдельных блоков для метаданных файловых систем. Слишком их много, чтобы учитывать все разновидности. Алгоритм выравнивания износа сводится к анализу счетчиков записей в блоки, которые могут быть как в структурах транслятора, так и в служебных данных в самих страницах блока. При изменении содержимого блока у которого значение счетчика записей заметно больше, чем у свободных блоков выберется новый блок с наименьшим значением.
В буфер попадает все то, что часто используется. Но оно все равно оперативно пишется в NAND. Либо целиком блоками, либо блок-апдейтами. Если бы просто держать данный в RAM и не особо торопиться с обновлением их в NAND, то первое внезапное отключение питания приводило бы к катастрофической потере данных (в первую очередь серьезные потери в метаданных файловой системы). Микропрограмма SSD при буферизации оперирует определенными LBA диапазонами, которые часто запрашиваются и на основании этих запросов обычно выбирает, что подольше задержать в ОЗУ SSD.
P.S. простите, за слишком скомканный комментарий и сильное упрощение.
А можно ли конкретно указать какая именно модель вызвала ваше неудовольствие и какая именно модель порадовала. Есть подозрение, что вы сравнили слишком разные диски. Потому как в повседневное работе в которой хватает рутины в виде копирования большого количества файлов разного размера, я не могу выделить какого-либо из производителей, как конкретного аутсайдера. Скорее наоборот подмечаю, что продукты разных производителей с примерно одинаковой плотностью записи и скоростью вращения вала показывают схожие результаты.
Так может измерьте? Покажите практический пример при котором в схожих по характеристикам накопителями разных производителей будет заметно существенное превосходство идеологии работы микропрограммы. Потому как в обычных задачах копирования большого количества файлов разного размера (около 250 000 суммарным объемом 100Гб с SSD), мне не удалось увидеть заметной разницы.
Кстати, хотелось бы уточнить, а на основании чего вы вообще рассказываете об идеологии работы микропрограммы какого-либо из накопителей? Из какого источника взята информация? Если это самостоятельная работа с дизассемблированной фирмварью, то можно бы было показать немножечко скринщотов из IDA?
Все диски читают мелкие файлы медленно, но провал именно у тошибы.
Осмелюсь предположить, что вы либо проводили тест совершенно разных линеек накопителей, либо предвзято относитесь к дискам Toshiba, либо заблуждаетесь на основании где-то услышанных недостоверных данных.
Услышав ваше заявление, я решил проверить, есть ли основания упрекнуть все виды дисков Toshiba в чрезмерной медлительности. Для этого я взял два 2,5" накопителя: Toshiba MQ01ABD075 и Hitachi HTS541075A7E630. Накопители емкостью по 750гб, имеют по 2 пластины и по три головки. Плотность записи сопоставима. Один 2013 года выпуска, второй 2014. Диски совершенно исправны и нигде оффлайн скан не вносит лепту в тестирование. Взяты относительно старые диски, чтобы в результаты тестирования не вмешивались хитрости современных SMR дисков, которые в штатных условиях в тестовом ПО покажут более красивые значения, но это не будет справедливым результатом. Создаем по одному разделу на всю емкость на каждом диске и запускаем CrystalDiskMark
результат тестирования Toshiba MQ01ABD075
результат тестирования Hitachi HTS541075A7E630
Можете видеть сами, что результаты тестирования похожих дисков дают похожие результаты (отклонения в пределах 10%). Причем на других экземплярах этих же семейств отклонения с небольшой погрешностью могут отличаться, так как плотность зон у каждого накопителя будет разной.
SMR диски это отдельный разговор. Ловкие манипуляции с медиакешем помогут показать красивые цифры в тестировании, особенно с небольшими объемами данных. Но куда интереснее будут показатели скорости при работе с данными, которых нет в медиакеше. Могу сказать сразу, что эти показатели неприятно удивят (значения будут намного хуже, чем у обычных дисков).
Мне вот кажется, что это позиционирование — «для видеонаблюдения» — только отпугнёт рядового обывателя. Он будет долго стоять и сомневаться, а заработает ли этот винт в его компьютере, а плохо это или хорошо, что он «для видеонаблюдения», а ну его, куплю-ка я другой…
И правильно сделает, что для компьютера купит диск у которого настройки микропрограммы оптимизированы лучше для обычных задач.
Нужно чётко пояснять, что любой жёсткий диск будет работать там-то и там-то, а отличия заключаются в том-то и том-то и несоблюдение рекомендаций ничем не грозит (или грозит тем-то и тем-то).
работать будет, но у производителя есть изделия, которые лучше подойдут для той или иной роли. На примере одного из семейств WD как-то показывал, что из одной аппаратной платформы получают накопители для разных задач посредством конфигурирования микропрограммы.
Выбирая диск лучше прислушиваться к рекомендациям производителя.
Нет предупредительного чтения: если нужно прочитать один единственный сектор — будет прочитан один сектор. О том что можно прочитать все сектора на этой позиции головок (диск-то вращается) — умная электроника не догадывается.
Отключение различных read look ahead в различных накопителях приводит к скоростям при которых пропускная способность PIO-0 кажется вполне уместной. Если дизассемблировать микропрограмму тошибы то полагаю там тоже увидим свои алгоритмы упреждающего чтения. На примере других семейств можно сказать, что при чтении в обычном режиме и натыкании на дефекты мы получим огромные паузы, которые намного больше, чем попытка чтения одиночного дефекта (даже с учетом обновления SMART, попытки переназначения и т.п.), что явно намекает на наличие упреждающего чтения. Как и факт достижения высокой линейной скорости чтения.
Про видеонаблюдение они не зря написали — с большими блоками эти диски работают замечательно. А вот с мелкими — хуже старой флеш карты.
по большому счету все жесткие диски при записи мелких блоков в разные места будут показывать провальную производительность. И если начать смотреть в цифрах именно похожие диски у разных производителей, то отличия вроде бы и можно увидеть, но назвать их существенными, которые в повседневной жизни будут заметны на глаз, мы вряд ли сможем. Кроме этого у чрезмерной буферизации и всякой самодеятельности с отложенными записями есть обратная сторона медали. В случае аварийного отключения питания может так оказаться, что слишком много данных оказались недописанными и получим более масштабные потери.
32*4=128Мбит/с или 16мб/с. Какая-то детская скорость, 100мб/с на запись умели десктопные харды уже 10 лет назад. В конце диска скорость проседала, но не настолько.
Линейная запись и запись в 32 разных места — это две большие разницы. Во втором случае огромные затраты времени на позиционирование.
Ещё можно предположить, что пишущий софт решил избавиться от файловой системы и писать данные напрямую по адресам секторов. Для этого общее количество секторов поделил на количество камер, и выделил условные 32 раздела диска, и теперь при записи каждого блока всех камер за период времени головка делает N раз позиционирование. И производитель гарантирует, что диск успеет все записать в таком режиме.
В таком режиме вряд-ли успеет, ибо затраты времени на позиционирование будут катастрофически велики.Проблему решить можно только приличной буферизацией, чтобы писать относительно крупными порциями по каждому из потоков и уменьшить количество перемещений головок.
Кстати пишущий софт многих видеорегистраторов использует проприетарные файловые системы. Например такие как WFS В которых все описание объектов сводится к описанию цепочки блоков, дате, времени и номере камеры.
Но ведь так, я надеюсь, никто не делает. Обычно все же пишут единым блоком, который уже содержит сегменты от каждого видеопотока, или сбрасывают буфер по очередно от каждой камеры.
обычно сброс потока привязан еще и ко времени. в случае камер с малым битрейтом будет слишком редкий сброс и как следствие в случае аварий может не успеть быть сброшено нужное. Поэтом блоки могут заполняться частями, что в итоге увеличивает нагрузку в виде перемещений БМГ. На примере с WFS0.4 достаточно хорошо можно понять какую нагрузку на диск дает запись в несколько потоков.
Вы ошиблись на три порядка. 1 миллион калорий — это 1000ккал.
калорийность сахара по разным источникам 370-400ккал на 100 грамм. Итого речь лишь о 250-270 граммах сахара.
Уже несколько раз натыкался на SSD диск, который при заполнении больше ~95% начинает выдавать ошибку чтения блоков. Ошибочных блоков со временем становится все больше и больше. Проблема не исчезает, если свободного места добавить. После клонирования такого диска, сбрасываю его с помощью метода «ssd secure erase» и диск снова как огурчик.
Износ NAND памяти. При полном заполнение в работу вступит почти вся память, в том числе и блоки которые перенесли большое число записей. Просто удаление файлов не обязательно приведет к исключению проблемного блока из транслятора. Security Erase обрабатывается микропрограммой так: очистка NAND и сброс транслятор и по мере заполнения использовать блоки с минимальным числом записей.
И как такого избежать? (была идея создавать раздел не во весь диск, но проверить руки так и не дошли)
Замена SSD. Создавать меньший раздел можно, но все больше и больше будет блоков с проблемными страницами. И все равно проблема начнет проявляться раньше и раньше. А если проблемный блок попадется на служебку (на те же структуры транслятора), то ваш SSD сразу превратится в кирпич после рестарта.
1. массы троса.
2. массы кабеля
3. учесть трение и того и другого о стенки трубы
4. учесть особенности сцепления колес со стенками трубы
и на фоне этих данных кажущаяся простой инженерная задачка перестает такой быть.
1. Ошибки в драйвере ОС. Некорректно разбирается регистр ошибок и в некоторых случаях забирается содержимое пустого буфера. Отсюда гладкий скан, но прочитанное в некоторых точках не соответствует записанному.
2. Ошибки в микропрограмме жесткого диска.
Для исследования ошибок желательно сделать множественные попытки записи и чтения с сохранением результата чтения в файлы. После исследовать разночтения между тем что прочиталось в разных версиях и тем, что должно было быть записано.
Это ошибки чтения не из-за ОЗУ. Ошибки в ОЗУ зачастую никак не регистрируются, если не проводить дополнительный контроль целостности данных, как например это делали вы, и носят случайный характер. А вот ошибки в виде некорректного ремапа, когда точечно накопитель может быстро выдавать ABR при попытке чтения или устанавливать иные биты в регистре флагов и эти ошибки не регистрируются драйвером работающим с устройством могут приводить к ситуации описанной вами.
Автору удалось решить задачку подручными средствами. Правда туда были привнесены существенные тормоза в виде проверки прочитанного содержимого. Но в любом его стараниями был достигнут результат.
1. Все данные пишутся в зашумленном виде, а не в чистом, как представляется автору. При записи пользовательских данных нет разницы будут там нули или случайный паттерн. Это действие даст одинаковый результат в плане дальнейшего качества чтения.
2. У микропрограмм жестких дисков достаточно серьезные методы контроля целостности прочитанных данных. При некорректируемых за счет ECC ошибках чтения при стандартных АТА командах современный накопитель не отдаст никаких данных, а только сигнализирует об ошибке в регистре ошибок.
3. Искажение данных может происходить в ОЗУ накопителя при условии ее неисправности.
Если есть желание проверить контроллер на предмет исправности его буферного ОЗУ, то в той же Victoria можно выполнить тест записи с DDD. В случае появления читабельных секторов с искаженным содержимым можно будет сделать вывод о необходимости замены PCB с переносом ПЗУ. Этот тест будет работать заметно быстрее варианта предложенного автором. В остальном все сведется к количеству циклов записи-чтения с переназначением (Remap). Если накопитель не совсем труп, то этими стараниями можно будет получить что-то хоть частично годное к эксплуатации. Если же проблема серьезна, то все эти действия приведут к запиливанию пластин.
Попытки заочной отбраковки однозначно не имеют смысла в силу того, что не стоит гадать, где именно находятся проблемы. Необходимо проводить нормальное тестирование диска. И на основании тестов делать вывод о том стоит ли далее этот диск пытаться обслуживать или сразу отправить в утиль.
MFT может быть фрагментирована и ее куски могут быть разбросаны по всему диску.
MFT mirror — это всего лишь 4 записи (при стандартном размере записи 1024 байта — это 4кб). Также некоторые дисковые менеджеры ставят позицией MFT Mirr второй кластер.
По всему диску хаотично разбросаны индексные записи, в некоторых из них частота перезаписей была очень высокая и вероятность возникновения проблемы не ниже, чем в местах расположения MFT.
Пример разброса индексов по диску. обратите внимание на размер ползунка и его позицию.
Пример: диск обычного пользователя.
Таблица разделов.
Построим карту расположения фрагментов MFT
Результат построения.
предсказуемым оказался только первый фрагмент, который не самый крупный.
и получим много новых красивых «рисунков» на поверхности пластин.
без увеличения это будет так
повреждения полимерного покрытия могут иметь место, но проход головок над ними пока что не приводит к новым контактам слайдера и поверхности. Но это событие носит вероятностный характер.
есть нюанс. если диск уже обнаружил дефекты, то немалая вероятность, что просто так держать головки на парковке он не будет. А будут весьма активно работать процедуры оффлайн скана (не во всех семействах).
Вы заблуждаетесь. Вы не можете создать раздел только в границах одной физической пластины. Логическое пространство реализуется из зон чередующихся между всеми головками. Например реализация логического пространства в жестком диске Seagate ST9500325AS. На скриншоте можно увидеть, как идет чередование мини-зон.
Чередование зон в жестком диске Samsung HD753LJ
Умирает там, где произойдет контакт слайдера и поверхности и появится первичное повреждение полимерного покрытия. Если повреждение полимера серьезно, то как бы вы не пытались создать разделы не затрагивающие места дефектов, то все ваши старания все равно будут насмарку по причине того, что проблему усугубят процедуры оффлайн сканирования.
анализ метаданных файловых систем позволяет установить набор актуальных дисков в 99% случаев. Если расхождение между отвалами дисков совсем малозначимое, то необходимо анализировать содержимое последних файлов.
С помощью профессиональных инструментов, таких как Raid Explorer или PC3000Dataextractor RAID edition можно собирать разные варианты массива виртуально (поочередно исключая разные диски и каждый раз вести комплекс анализов). В случае серьезных расхождений данных не особо сложно определить неактуальный диск даже в обычном HEX редакторе.
Разумеется для этого необходимо знать устройство файловых систем и устройство различных типов файлов.
В случае VMFS при малой разнице по времени исключения дисков из массива можно и не определить тот, который нужно исключить при анализе метаданных VMFS. В таком случае необходимо анализировать файловые системы и данные в виртуальных машинах.
В гонке за производительность и за сохранение ресурса, микропрограммы NAND накопителей не увлекаются перезаписями статичных данных к которым нет никаких обращений. Они лежат мертвым грузом и блоки занимаемые ими не участвуют в ротации.
В итоге в DR лабораториях частые гости SSD которые были заполнены большим количеством статичных данных и в активной ротации блоков принимало участие слишком малое число блоков отчего и возник износ отдельных областей NAND памяти.
Кроме этого в АТА стандарте как-то не особо предусмотрена коммуникация ОС и SSD на предмет того, что грядет в ОС (например планируемое отключение). В связи с чем самовольные перезаписи в неудачные моменты — это дополнительные риски отказа устройства, которые заметно выше рисков получения нечитаемых данных из-за утечек зарядов.
Контроллер как правило оперирует блоками, которые в свою очередь состоят из группы NAND страниц (64,128 и т.п.). Размеры страниц в NAND микросхемах обычно все же не сотни килобайт, а 528, 2112, 4224, 4320, 8576, 8640, 8832, 8896, 9216, 17664, 18048, 18336 и др. Малые размеры справедливы для старых SLC микросхем, для современных TLC размеры поболее. Такие странные размеры потому, что кроме пользовательских данных необходимо хранить служебные данные (ECC, флаги, номера блоков, счетчики записей и т. п.).
Как-то на достаточно простом примере показывал организацию работы NAND контроллера и NAND памяти. В современных SSD алгоритмы будут более сложными, ну суть примерно такая же.
Для того, чтобы SSD не превращался в коматозника при записи мелких объектов применяется буферизация, а также вводится понятие блок-апдейтов. Это блоки в которых записываются отдельные страницы для разных блоков, которые точечно накладываются на транслируемое логическое пространство.
Например при восстановлении данных, когда нет возможности оперировать штатными структурами транслятора обычно необходимо проводить поблочную сборку и находить отдельные блок-апдейты и накладывать их данные отдельными страничками поверх собираемого поблочно для получения актуальных данных.
принцип работы таков: любой физический блок в логическом банке, может выполнить любую роль в реализуемым этим банком логическом пространстве. Посему нет отдельных блоков для метаданных файловых систем. Слишком их много, чтобы учитывать все разновидности. Алгоритм выравнивания износа сводится к анализу счетчиков записей в блоки, которые могут быть как в структурах транслятора, так и в служебных данных в самих страницах блока. При изменении содержимого блока у которого значение счетчика записей заметно больше, чем у свободных блоков выберется новый блок с наименьшим значением.
В буфер попадает все то, что часто используется. Но оно все равно оперативно пишется в NAND. Либо целиком блоками, либо блок-апдейтами. Если бы просто держать данный в RAM и не особо торопиться с обновлением их в NAND, то первое внезапное отключение питания приводило бы к катастрофической потере данных (в первую очередь серьезные потери в метаданных файловой системы). Микропрограмма SSD при буферизации оперирует определенными LBA диапазонами, которые часто запрашиваются и на основании этих запросов обычно выбирает, что подольше задержать в ОЗУ SSD.
P.S. простите, за слишком скомканный комментарий и сильное упрощение.
Кстати, хотелось бы уточнить, а на основании чего вы вообще рассказываете об идеологии работы микропрограммы какого-либо из накопителей? Из какого источника взята информация? Если это самостоятельная работа с дизассемблированной фирмварью, то можно бы было показать немножечко скринщотов из IDA?
Осмелюсь предположить, что вы либо проводили тест совершенно разных линеек накопителей, либо предвзято относитесь к дискам Toshiba, либо заблуждаетесь на основании где-то услышанных недостоверных данных.
Услышав ваше заявление, я решил проверить, есть ли основания упрекнуть все виды дисков Toshiba в чрезмерной медлительности. Для этого я взял два 2,5" накопителя: Toshiba MQ01ABD075 и Hitachi HTS541075A7E630. Накопители емкостью по 750гб, имеют по 2 пластины и по три головки. Плотность записи сопоставима. Один 2013 года выпуска, второй 2014. Диски совершенно исправны и нигде оффлайн скан не вносит лепту в тестирование. Взяты относительно старые диски, чтобы в результаты тестирования не вмешивались хитрости современных SMR дисков, которые в штатных условиях в тестовом ПО покажут более красивые значения, но это не будет справедливым результатом. Создаем по одному разделу на всю емкость на каждом диске и запускаем CrystalDiskMark
результат тестирования Toshiba MQ01ABD075
результат тестирования Hitachi HTS541075A7E630
Можете видеть сами, что результаты тестирования похожих дисков дают похожие результаты (отклонения в пределах 10%). Причем на других экземплярах этих же семейств отклонения с небольшой погрешностью могут отличаться, так как плотность зон у каждого накопителя будет разной.
И правильно сделает, что для компьютера купит диск у которого настройки микропрограммы оптимизированы лучше для обычных задач.
работать будет, но у производителя есть изделия, которые лучше подойдут для той или иной роли. На примере одного из семейств WD как-то показывал, что из одной аппаратной платформы получают накопители для разных задач посредством конфигурирования микропрограммы.
Выбирая диск лучше прислушиваться к рекомендациям производителя.
Отключение различных read look ahead в различных накопителях приводит к скоростям при которых пропускная способность PIO-0 кажется вполне уместной. Если дизассемблировать микропрограмму тошибы то полагаю там тоже увидим свои алгоритмы упреждающего чтения. На примере других семейств можно сказать, что при чтении в обычном режиме и натыкании на дефекты мы получим огромные паузы, которые намного больше, чем попытка чтения одиночного дефекта (даже с учетом обновления SMART, попытки переназначения и т.п.), что явно намекает на наличие упреждающего чтения. Как и факт достижения высокой линейной скорости чтения.
по большому счету все жесткие диски при записи мелких блоков в разные места будут показывать провальную производительность. И если начать смотреть в цифрах именно похожие диски у разных производителей, то отличия вроде бы и можно увидеть, но назвать их существенными, которые в повседневной жизни будут заметны на глаз, мы вряд ли сможем. Кроме этого у чрезмерной буферизации и всякой самодеятельности с отложенными записями есть обратная сторона медали. В случае аварийного отключения питания может так оказаться, что слишком много данных оказались недописанными и получим более масштабные потери.
В таком режиме вряд-ли успеет, ибо затраты времени на позиционирование будут катастрофически велики.Проблему решить можно только приличной буферизацией, чтобы писать относительно крупными порциями по каждому из потоков и уменьшить количество перемещений головок.
Кстати пишущий софт многих видеорегистраторов использует проприетарные файловые системы. Например такие как WFS В которых все описание объектов сводится к описанию цепочки блоков, дате, времени и номере камеры.
обычно сброс потока привязан еще и ко времени. в случае камер с малым битрейтом будет слишком редкий сброс и как следствие в случае аварий может не успеть быть сброшено нужное. Поэтом блоки могут заполняться частями, что в итоге увеличивает нагрузку в виде перемещений БМГ. На примере с WFS0.4 достаточно хорошо можно понять какую нагрузку на диск дает запись в несколько потоков.
калорийность сахара по разным источникам 370-400ккал на 100 грамм. Итого речь лишь о 250-270 граммах сахара.
Износ NAND памяти. При полном заполнение в работу вступит почти вся память, в том числе и блоки которые перенесли большое число записей. Просто удаление файлов не обязательно приведет к исключению проблемного блока из транслятора. Security Erase обрабатывается микропрограммой так: очистка NAND и сброс транслятор и по мере заполнения использовать блоки с минимальным числом записей.
Замена SSD. Создавать меньший раздел можно, но все больше и больше будет блоков с проблемными страницами. И все равно проблема начнет проявляться раньше и раньше. А если проблемный блок попадется на служебку (на те же структуры транслятора), то ваш SSD сразу превратится в кирпич после рестарта.