очень много воды, но есть любопытное, да.
чтоб не искать по всей простыне - эти абзацы
А вот так могут себя вести бенчмарки. Слева — запуск чтения на чистом диске, справа — после его прописывания тестом записи. Почему такая разница? Пока данные физически не записывались, никакого соответствия LBA—PBA просто нет. А читаем-то мы по логическим адресам — которых нет, в чём диск убеждается сразу же при обращении к транслятору! И эта скорость никак не зависит от места расположения «предполагаемых» данных, да и время доступа к ним около нуля, когда никакой физический доступ не требуется. Прописали диск последовательно? Получили такую же картинку, как и на обычном жестком диске. Прописали бы не последовательно — получили бы и чтение по произвольным адресам.
Последнее как раз и является проблемой данного подхода. В принципе, такое можно заметить и на SSD, но не в бытовых сценариях, а специально постаравшись. Время доступа при чтении у флэш-памяти низкое. И практически не зависит от того, какой блок запрашивался перед этим. Поэтому существенной разницы между произвольной и последовательной адресацией часто нет. А жесткие диски — устройства, все-таки, больше последовательные. Не в той степени, как магнитные ленты, но хаотические перемещения блока магнитных головок занимают достаточно большое время. Соседние блоки друг за другом читаются быстро, однако... Если мы одновременно ведем запись нескольких файлов по произвольным адресам, то на диске физически получится каша — данные расположатся в порядке поступления. Относящиеся к разным файлам вперемешку. А логические блоки при этом могут идти последовательно — но их последовательное (с точки зрения логических адресов) чтение приведет к чтению с произвольной (физической) адресацией. Полный аналог фрагментации — только на уровне ниже файловой системы, так что и наводить порядок куда сложнее. И даже один файл может размазать по всему диску — если мы не просто запишем его один раз и оставим в покое, а будем модифицировать.
Есть ли нормальный универсальный способ борьбы с такой фрагментацией? Теоретически диск сам будет заниматься этим в простое — и действительно занимается. Это даже во время тестирования заметно — после окончания теста на запись с произвольной адресацией можно слушать стрёкот головок еще час, а то и больше. Всегда есть чем заняться — например, те же ленты уплотнить. Если в них остался только мусор, то добавить ленту к списку свободных и использовать в дальнейшем для записи (в отличие от SSD дополнительный цикл стирания даже не требуется). Если почти только мусор, то все ценные блоки можно скопировать в другую ленту — и свести задачу к уже решенной. Даже отдельные блоки при желании и свободном времени можно подвигать. Но всё это легко для внутреннего диска, а внешние и подключают на короткое время. Потом отключают — и заниматься своими делами им уже некогда. Хотя иногда проблемы можно и исправить. Допустим, скачали мы несколько файлов тем же торрент-клиентом — и легли они вперемешку. Дальше просто копируем (не перемещаем!) их в пределах того же диска — и получаем «нормальную» последовательную запись. Либо просто на другой диск — там они будут нормальными. А вот на источнике могут остаться «дырки», которые в дальнейшем будут как-то заполняться новой информацией. В описанном примере — не останутся, но ведь мы можем переместить на другое устройство или удалить отдельный файл, оставив прочие скачанные надолго — и останется у нас фрагментированное свободное пространство. Которое уборка мусора позднее может и консолидировать — а может и нет.
Можно ли как-то ускорить и упорядочить процесс вручную? Нет. Сама идеология Drive Managed SMR заключается в том, что ни операционная система, ни прикладные программы с внутренней кухней устройства незнакомы. Они оперируют только LBA — а дальше уже не их дело. Так что, например, утилиты дефрагментации будут наводить порядок именно в плане логических адресов — что при физической фрагментации не только бесполезно, но даже и вредно. Так что есть только один способ борьбы с ней — перенести все данные на другой диск, этот полностью очистить, а данные потом записать обратно. Таким образом, мы опять вернемся на исходные позиции, что и требуется. Если, конечно, оставить за скобками вопрос, где взять этот самый «лишний» диск и время на копирование туда-обратно терабайтов информации. И не забывать о том, что при «неправильной» эксплуатации эту процедуру придется повторять регулярно. Как только пользователь начинает баловаться с торрентами, либо просто редактировать файлы непосредственно на таком диске, так сразу же фрагментация физических секторов возвращается — и снова начинает нарастать.
Радикальным образом проблему можно решить при помощи Host Managed SMR, когда и операционная система «знает», что ей подсунули, и файловые системы специальным образом оптимизированы под черепицу, так что основные модифицируемые структуры всегда будут находиться в областях с «разрешенной» произвольной записью (проще говоря в том же медиакэше), а в ленты будут попадать только неизменяемые данные и только последовательно. Но этот подход используется исключительно в специальных моделях для датацентров, поскольку как раз и требует наличия «умного» программного обеспечения, да и специальных дисковых контроллеров. Проще говоря, под него нужно переделывать всю инфраструктуру. А в быту применяется исключительно DM SMR — придуманный для того, чтобы черепичные диски могли «прикидываться» обычными. Что у них получается — но вызывает те или иные проблемы при эксплуатации. Ничего не дается бесплатно — и снижение стоимости хранения информации тоже.
В общем, подытоживая, очень многое при таком подходе зависит от нагрузок, да и вообще сценариев использования. В роли банальной файлопомойки, куда файлы (желательно большие) просто копируются штатными средствами, потом лежат и иногда удаляются подобный диск может работать годами — и никто не заметит никакого подвоха. Использовать же подобный винчестер в качестве рабочего можно. Как долго? Да сколько угодно. Но не забывая, что проблемы имеют тенденцию накапливаться. Даже SSD, где они куда менее выражены, можно «замучить» некоторыми сценариями до такого состояния, что тормоза будут видны невооруженным глазом. После чего, впрочем, можно просто снять образ, прогнать Secure Erase, восстановить информацию из образа — и продолжать работать как ни в чем не бывало. Но с дисками на несколько терабайт такое проделывать куда сложнее. Хотя и тоже реально. А понадобится такое делать или нет — зависит больше не от диска, а от того, как его будут использовать. Возможно, что до каких-то заметных проблем не доживет никогда. Особенно если не перенапрягать устройство прямой работой, а просто использовать его для хранения «холодных» данных. Или резервных копий, например.
Есть опасения, что это не ваш случай? Тогда лучше заплатить побольше.
....................
Многопоточный режим и возможные в данном случае оптимизации очереди команд немного улучшают картину, но радикально ее исправляет исключительно введение динамической трансляции. Однако это палка о двух концах — данные записываются для того, чтобы их потом читать. А такой метод ускорения записи приводит к появлению сложноразгребаемой «каши» на диске: когда последовательные логические блоки следуют на деле вперемешку с точки зрения физической организации. Как уже было сказано выше, подобная фрагментация со временем точно будет снижать производительность. Так что банальный факт — жестким дискам именно работа с данными противопоказана: она будет медленно выполняться либо сразу, либо потом. Но будет. И именно медленно.
