Скоростные внешние SSD и политики кэширования дисков в Windows, а также способы измерения их влияния на производительность
Методика тестирования накопителей образца 2021 года
Большинство посвященных внешним SSD материалов представляют собой обзоры конкретных устройств или «полуфабрикатов» для их сборки. Однако существуют у этих устройств и общие особенности. И даже проблемы. И даже такие проблемы, которые формально не их проблемы —, но портят жизнь как раз их пользователям. Некоторым граблям, заботливо подложенным производителями программного обеспечения, уже исполнилось несколько десятилетий, но наступают на них всё новые и новые пользователи. Включая и родившихся позднее этих граблей :)
В общем, в компьютерном мире (как и в любом другом) нет ничего более постоянного, чем временное. Относится это и к политике кэширования внешних накопителей, которую в Microsoft несколько раз меняли, но состояние по умолчанию и сейчас далеко не то что от идеального, но даже и от нормального. Формулируется проблема просто: диск тормозит на записи файлов, хотя показывает нормальные результаты в низкоуровневых утилитах. Дело объяснимое: алгоритмы работы какого-нибудь CrystalDiskMark в принципе не похожи на «рабочие», причем и системное кэширование эта программа не использует (а вот сторонними утилитами производителей SSD ее обмануть можно), однако сама по себе такая разница хорошо подпитывает конспирологические теории о «дутых скоростях» и «попугайных бенчмарках». На деле же проблема легко решается всего одной галочкой в настройках. И длится это уже много лет и много windows —, но не меняется. Причем проблема широко не афишируется, поэтому не все в курсе. А создатель системы, повторимся, нормализовать ее поведение либо не может, либо не хочет. Поэтому приходится разбираться самостоятельно.
История вопроса и современное состояние дел
На заре DOS диски не кэшировались — вообще и никакие. Проблем это не вызывало: во-первых, огромное количество персоналок поставлялись исключительно с флоповодами, а кэшировать работу с дискетками — так себе затея;, а в-главных, большинство программ были простыми и с дисками нередко работали медленнее, чем те позволяли. Кроме того, свободной памяти для дискового кэша практически не было — 640 КБ были огромным значением в начале 80-х, так что в первые IBM PC на деле столько поставить даже физически было невозможно (а продавались многие компьютеры со 128–256 КБ), но вскоре и этого программистам оказалось маловато. А больше мегабайта DOS «по-человечески» адресовать не могла, причем немалая часть адресного пространства была зарезервирована для доступа к памяти видеоадаптера и других устройств, так что придумывать что-либо серьезное в таких условиях было незачем.
К концу 80-х ситуация с аппаратным и программным обеспечением немного изменилась, так что в MS DOS 4.01 появилось и кэширование дисков. Однако в полной мере актуальным оно стало лишь после начала внедрения Windows 3.x — с псевдомногозадачным режимом работы и прочими ранее (почти) невиданными на РС-рынке особенностями. В целом SmartDrive работал и под DOS, но подавляющее большинство созданных для этой системы программ его участия не замечало. Зато пользователям был повод подискутировать, стоит ли использовать кэширование вообще и включать ли кэширование записи. С последним уже тогда не все обстояло гладко: хотя программа по умолчанию кэшировала только жесткие диски, а не дискеты и прочее подобное, зато и компьютеры было принято выключать просто тумблером. А во времена до АТХ это было эквивалентно простому пропаданию питания — со всеми вытекающими. В частности, и с несохраненными на диск данными.
Поэтому в Windows разработчики немалое внимание уделили последнему вопросу, да и в разработках компьютерных стандартов 90-х Microsoft всегда принимал активное участие. Благодаря чему мы сначала познакомились с экраном «Теперь питание компьютера можно отключить», а затем про него благополучно забыли, благо реализация программного выключения в АТХ позволила завершать работу корректно в 99,(9)% случаев. Соответственно, проблема с кэшированием фиксированных дисков отпала практически полностью. Зато появилась новая напасть: вместо накопителей на сменных носителях в ход пошли сменные накопители.
Первое время эту проблему можно было игнорировать как не массовое явление. Массовым оно начало становиться где-то в конце 90-х — вместе с интерфейсом USB 1.1 (реализация 1.0 оказалась неработоспособной, поэтому про нее никто обычно не вспоминает) и Windows 98 (с относительно нормальной поддержкой нового интерфейса). Но USB-накопители та система напрямую не поддерживала, требовалась установка сторонних драйверов. После чего UMS-устройство (USB Mass Storage — первый допотопный протокол работы) для системы становилось, по сути, еще одним внутренним жестким диском. С одним лишь нюансом: его можно было легко отключить простым выдергиванием провода. А это часто вело к потере данных и даже повреждениям файловой системы — ведь при включенном кэшировании записи и небезопасном отключении данные могут не записаться физически. И ладно еще файл не запишется — вот если в момент выдергивания провода (или устройства целиком — первые USB-флэшки быстро становились популярными во многом из-за компактности) происходила модификация таблиц размещения файлов, то в последних мог оказаться мусор. Приходилось исправлять — и не всегда удавалось ограничиться автоматическим режимом.
По этой причине в более новых Windows 2000 и ME появилась не только непосредственная встроенная поддержка UMS, но и утилита для безопасного отключения накопителей. Казалось бы, проблема решена: тыкаем в иконку на панели задач, выбираем нужное устройство, отключаем, вся информация из кэша корректно записывается на диск, и всё. На деле же количество жалоб продолжало расти, потому что USB-накопители становились все более популярными, а вот отключать их положенным способом пользователи не желали. Кто-то даже и не знал о нем, поскольку способ не интуитивный. А кому-то просто лень было — ведь выдернуть флэшку гораздо проще, чем куда-то тыкать-выбирать. А еще и свои неудобства этот механизм добавлял. Например, пошуршав блинами, внешний жесткий диск сообщал, что отключить его все-таки нельзя. И так несколько раз — до перезагрузки… Или пока пользователю не надоест — и он все-таки просто не дернет провод. Кроме того, в списке доступных для отключения могли оказаться и внутренние диски — так любили себя вести SATA-драйверы Nvidia, например. В итоге появлялась немалая вероятность ошибиться — и отключить что-нибудь не то. С картоводами безопасное отключение и вовсе вело себя некорректно, отключая устройство целиком, так что для простой замены карты памяти его приходилось выдергивать из разъема и включать обратно (а в случае внутренних моделей — вообще перезагружать компьютер). В общем, неудобств было много. При этом простое выдергивание в большинстве случаев к проблемам не приводило, поскольку всё успевало корректно записаться: данные не могут лежать в дисковом кэше бесконечное время, так что достаточно было не хвататься за провод буквально несколько секунд после окончания активности. Но вероятность того, что что-то пойдет не так, все равно была отлична от нуля. А будучи умноженной на десятки миллионов пользователей, по несколько раз в день что-то отключающих, давала и заметное количество сообщений о проблемах.
Как с ними покончить гарантированно? Известно, что построение демократии может начинаться исключительно со строительства концлагерей для недовольных демократией — вот в этом направлении и решено было двигаться. В Windows XP политикой по умолчанию для USB-накопителей стала оптимизация под безопасное отключение. В этом случае система просто полностью выключает кэширование записи, так что проблемы возможны исключительно при отключении устройства непосредственно в процессе обновления информации. Но тут уж сам себе злобный Буратино:) Зато ждать ничего не нужно, никакие кнопочки искать не нужно. Однако скорость прямой записи всегда ниже, чем у записи с кэшированием, так что осталась возможность вернуть всё, как было. Но уже самостоятельно — зная, что хочешь получить и чего лишаешься. Не обошлось без эксцессов и здесь: в частности, эксперименты показали, что кэширование записи Windows XP на самом деле включала только для NTFS-разделов. Так что в случае USB-накопителей с более популярной тогда FAT32 производительность оказывалась ниже, чем при работе с компьютером под управлением Windows 2000 или ME.
Эту проблему в последующих версиях Windows решили: современные оболочки дешевые кэшировать умеют всё. Но только если попросить их об этом специально. Как видно на скриншотах, и в Windows 10, и в Windows 11 по умолчанию запись на внешние накопители не кэшируется. Во всяком случае, пока мы говорим об USB. А вот Thunderbolt-накопители, как правило, работают со включенным кэшированием записи, и намного быстрее. Но и с ними были замечены случаи отключения кэширования по умолчанию — с соответствующим эффектом. Для USB же, повторимся, это стандарт. Поэтому если проблемы с производительностью не нужны, политику кэширования в обязательном порядке нужно менять. К сожалению, глобальной настройки для этого нет (документированной, во всяком случае) — всё делается для каждого накопителя на каждом компьютере индивидуально через «Диспетчер устройств».
Надо ли это делать на самом деле или прогресс интерфейсов и накопителей сделал кэширование ненужным? Как будет показано ниже, все-таки надо. Не всегда —, но для тех случаев, когда накопитель используется преимущественно для переноса информации, причем частота операций записи велика, сделать это нужно обязательно. Иначе придется терпеть существенное снижение производительности. Хотя и ситуации, в которых можно ничего не настраивать, тоже существуют. С обычными дешевыми USB-флэшками можно вообще не напрягаться — для большинства из них современные версии Windows кэширование записи включать все равно отказываются. Впрочем, там и скорости работы оставляют желать много лучшего. А вот если нужна именно высокая производительность внешнего SSD, его нужно настроить. Что это даст — посмотрим на конкретном примере. Только разберемся сначала с одним побочным, но тоже важным вопросом: почему не все тесты одинаково полезны.
Особенности работы низкоуровневых утилит и кэширование
К основной теме этот вопрос имеет косвенное отношение, но имеет. К тому же, когда-то нужно и им заняться. Например, почему мы (как правило) не используем тот же CrystalDiskMark и ему подобные при тестировании внешних накопителей? На дворе уже 2022 год, но некоторых читателей до сих пор смущает отсутствие в обзорах SSD (пусть и внешних) столь привычных IOPS. Включая и абсолютно абстрактные для потребительских внутренних моделей показатели на «длинных» очередях и тому подобное.
На деле причина проста: эти результаты иногда интересны в исследовательских целях, но бесполезны на практике. Собственно, и измерение последовательных скоростей в CDM (и других подобных утилитах) может быть полезно разве что для теста пропускной способности интерфейса, но и только. Реальная запись даже одного файла — это несколько обращений и изменений разных блоков. Да и чтение в общем случае — тоже. Поскольку чтобы что-то прочитать из файла, его нужно сначала найти на диске. Правда, с учетом кэширования служебных данных разделов (типа таблицы размещения файлов) современными системами в оперативной памяти последнее не так уж сильно «мешает» SSD, хотя до сих пор важно для жестких дисков. Запись же может испортить жизнь и тем, и другим. Причем чем с меньшими порциями данных мы работаем, тем больше влияние «паразитных» операций на основные. Грубо говоря, записать один файл размером 32 ГБ — это совсем не то же самое, что даже последовательная запись 32 файлов по 1 ГБ. А тем более — 32 тысяч файлов по 1 МБ в нескольких папках, это уже совсем другая история. Но полученные в том же CDM результаты не всегда можно распространять даже на первый, самый «простой» случай.
Низкоуровневые утилиты рассчитаны на получение пиковых показателей быстродействия. И именно под это оптимизирована вся логика их работы. С реальной файловой системой они (как правило) взаимодействуют всего один раз — в начале работы. Тот же CDM создает один файл заданного размера, а дальше читает и пишет данные в его пределах, после чего удаляет весь файл. Это позволяет нивелировать влияние «побочных» (для основной задачи теста —, но не с точки зрения практического использования диска) факторов, однако не позволяет оценить размер этого влияния. К примеру, в современных условиях временный файл CDM почти всегда оказывается внутри SLC-кэша SSD, и кэширование сказывается на результатах. Учитывая, что многие контроллеры сейчас читают данные из кэша быстрее (иногда намного), чем из основного массива памяти, а дать данным «отлежаться» низкоуровневые утилиты не позволяют… Эффект понятный.
А вот системный кэш в оперативной памяти CDM и другие низкоуровневые утилиты не используют. Осуществляется это просто: можно «скомандовать» Windows игнорировать кэш и всегда работать непосредственно с диском. А вот для сторонних утилит кэширования такое не предусмотрено. Так что при установке фирменных утилит, например, Samsung или Crucial можно заметить существенное «ускорение» SSD в бенчмарке. А можно увидеть его и без установки этих утилит — достаточно скачать исходники CDM, немного подредактировать («разрешив» кэшировать запись), откомпилировать — и всё. Будут те же безумные скорости, поскольку никакие «дисковые» операции до диска в принципе не достучатся, а все ограничится чтением и записью данных в пределах оперативной памяти.
Применительно к основному вопросу статьи это означает, что проблемы с кэшированием при помощи CrystalDiskMark и подобных программ выявить невозможно — они кэширование все равно не используют. Фактически низкоуровневые «попугаи» показывают лишь то, как накопитель мог бы работать в идеальных условиях. Иногда это тоже интересно. Но на практическое использование не натягивается. Разве что количество иллюстраций в обзоре внешнего SSD увеличить можно, да читателей перестанет смущать отсутствие таких результатов, поскольку все привыкли к их наличию. Вот и вся польза.
Тестирование
Методика тестирования
Исследование скоростных режимов USB 3.2 Gen1, Gen2 и Gen2×2 при помощи быстрого внешнего SSD на контроллере USB—NVMe ASMedia ASM2364
Методика подробно описана в отдельной статье, в которой можно более подробно познакомиться с используемым программным и аппаратным обеспечением. Здесь же вкратце отметим, что мы используем тестовый стенд на базе процессора Intel Core i9–11900K и системной платы Asus ROG Maximus XIII Hero на чипсете Intel Z590, что обеспечивает полную поддержку всех скоростных режимов USB 3.2 вплоть до Gen2×2 включительно.
В свое время мы воспользовались этим для изучения производительности разных режимов USB 3.2 при помощи USB-коробочки Orico M2PVC3-G20, укомплектованной WD Black SN850 2 ТБ. Тогда нас интересовали предельные характеристики, так что применялся и CrystalDiskMark 8.0.1 (который, как уже было сказано, для тестирования внешних накопителей мы обычно не используем). А сегодня он нам точно ничем не поможет. «Стандартный» же набор приложений — вполне. И тестировать будем опять в трех режимах — так картинка полнее.
Комплексное быстродействие
Краткое знакомство с новым тестовым пакетом PCMark 10 Storage
На данный момент лучшим комплексным бенчмарком для накопителей является PCMark 10 Storage, с кратким описанием которого можно познакомиться в нашем обзоре. Там же мы отметили, что не все три теста, включенных в набор, одинаково полезны: лучше всего оперировать «полным» Full System Drive, как раз включающим в себя практически все массовые сценарии — от загрузки операционной системы до банального копирования данных (внутреннего и «внешнего»). Остальные два теста — лишь его подмножества, причем, на наш взгляд, не слишком «интересные». А Full System Drive полезен в том числе точным измерением не только реальной пропускной способности при решении практических задач, но и возникающих при этом задержек. Усреднение этих метрик по сценариям с последующим приведением к единому числу, конечно, немного синтетично, но более приближенных к реальности оценок «в целом» (а не только в частных случаях) все равно на данный момент нет. Поэтому есть смысл ознакомиться с этой. Правда, она немного избыточна для оценки внешних накопителей — все-таки пока еще даже для многих владельцев внешних SSD идея использовать такой не вместе с, а иногда и вместо внутреннего кажется революционной. Однако, по нашему мнению, это как раз сценарии, в которых все преимущества этого класса устройств видны наиболее отчетливо. А для простого переноса файлов от компьютера к телевизору (бывает и такое) можно и внешним винчестером обойтись — оно еще и дешевле выйдет. Кстати, тесты на копирование файлов большого размера входят как раз только в Full System Drive, но не в два других набора PCMark 10 Storage, так что и с этой стороны альтернатив нет.
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 787 | 789 |
| USB 3.2 Gen2 | 1030 | 1028 |
| USB 3.2 Gen2×2 | 1226 | 1226 |
Однако в конечном итоге даже наличие большого количества операций записи (суммарный ее объем превышает 200 ГБ) все равно никак не влияет на результаты. Вообще. Понятно, что итоговый балл в основном определяется совсем другими операциями, однако полностью неизменным он может остаться только в одном случае: PCMark 10 Storage Full System Drive, подобно низкоуровневым бенчмаркам, кэширование в процессе работы не использует. Логика в этом есть, причем та же самая: бенчмарк используется для определения «чистого» быстродействия накопителей, а для «совсем системных» оценок есть другие тесты и пакеты. Но и недостатки такой логики тоже аналогичны: на практике бывает несколько иначе, чем показывает этот тест.
Работа с большими файлами
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 382,7 | 382,1 |
| USB 3.2 Gen2 | 964,8 | 960,6 |
| USB 3.2 Gen2×2 | 1703,9 | 1699,6 |
Напомним, что кэширование отключается (точнее, отключено по умолчанию) исключительно для операций записи, но не чтения. Однако при однократном чтении файла кэширование все равно не имеет значения —, а вот повторения теста могли бы изменить результаты, оставайся все данные в оперативной памяти. Впрочем, мы специально выбирали такой размер файлов, чтоб точно не остались — и даже вообще туда не поместились.
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 457,0 | 457,7 |
| USB 3.2 Gen2 | 1004,6 | 1001,7 |
| USB 3.2 Gen2×2 | 1964,3 | 1965,4 |
Но так или иначе, а результаты в обоих режимах должны быть одинаковыми. И должны зависеть от пропускной способности интерфейса, причем «выбирая» ее полностью лишь в многопоточном режиме. Все перечисленное выполнено — как, повторимся, и должно быть.
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 427,6 | 238,4 |
| USB 3.2 Gen2 | 928,4 | 403,4 |
| USB 3.2 Gen2×2 | 1626,1 | 441,2 |
А вот при записи данных ничего подобного не наблюдается: при выключении кэширования показатели падают вдвое. «Удвоенный» же режим USB 3.2 Gen2 (USB 3.2 Gen2×2) при этом полноценно «нагрузиться» не может, так что показатели и вовсе падают вчетверо. Файл большой, в оперативную память принципиально не лезет, а скорость записи — все равно принципиально разная. Так что если кэширование не настраивать, то переплачивать за поддержку самого скоростного режима USB незачем: даже через USB 3.2 Gen1 накопитель, после установки одной галочки, будет работать не медленнее, чем через USB 3.2 Gen2×2 в неоптимальном режиме.
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 481,6 | 235,7 |
| USB 3.2 Gen2 | 1022,2 | 391,6 |
| USB 3.2 Gen2×2 | 1905,4 | 438,8 |
Если же использовать запись большого числа меньших файлов, станет только хуже. Многопоточный режим лучше загружает интерфейс —, но только при включенном кэшировании. А что происходит при выключенном — видно наглядно. Даже «сверхбыстрый» внешний SSD в идеальных для себя условиях не может конкурировать с куда более дешевыми и медленными, но правильно настроенными.
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 473,5 | 300,5 |
| USB 3.2 Gen2 | 1040,6 | 546,8 |
| USB 3.2 Gen2×2 | 1850,9 | 712,8 |
Поскольку операциям чтения ничто не мешает, то падение суммарной скорости оказывается меньше, чем при чистой записи — как и должно быть. С другой стороны, бессмысленность покупки максимально быстрого (формально) накопителя при таком подходе все равно видна наглядно — сначала есть смысл воспользоваться бесплатным ускорением, а потом уже деньги тратить.
| Кэш включен | Кэш выключен | |
| USB 3.2 Gen1 | 343,5 | 308,1 |
| USB 3.2 Gen2 | 644,3 | 541,0 |
| USB 3.2 Gen2×2 | 945,7 | 677,6 |
Минимальное (на фоне прочих сценариев) падение производительности во многом связано с тем, что она здесь и сама по себе не слишком высокая. С другой стороны, запись в кэш или непосредственно на устройство с модификацией информации о файле — это немного разные вещи. Хотя данные в оперативной памяти не могут лежать бесконечно долго (на деле речь вообще идет о считанных секундах), но избежать немалого количества модификаций служебных данных все-таки можно. И, разумеется, нужно.
SSD с интерфейсами PCIe 3.0 и PCIe 4.0 на платформах AMD и Intel: история вопроса, немного теории и небольшое практическое сравнение
Казалось бы, всё ясно. Но полагаться на результаты единственного тестового пакета не совсем правильно. Несмотря на то, что он использует стандартные функции WinAPI, могут быть «особенности» и во внутренней работе. В конце концов, стандартные функции используют все —, но все по-разному. В прошлом году мы уже установили, что NASPT неадекватно работает на платформе AMD AM4 с SSD под PCIe Gen4, причем проблема в первую очередь заключалась как раз в операциях записи. Так что возникает вопрос:, а что мы в данном случае тестируем-то — накопитель или саму программу? С включенным кэшированием, впрочем, вопросов не остается: как и положено, упираемся именно в способности интерфейса. Однако выключение кэширования слишком сильно снижает производительность.
Копирование данных
Поэтому для полной ясности проведем простой качественный тест, копируя одиночный файл размером 32 ГБ на внешний SSD. Звучит просто — но, с учетом скоростей последних, не так уж всё просто на самом деле. В частности, понятно, что копировать данные с SATA SSD вообще бесполезно для любых режимов выше USB Gen3. И даже в случае «приличного» NVMe SSD скорость считывания данных с него все равно будет сказываться на результатах, не позволяя получить максимум. Но качественную оценку выполнить можно. И чтобы не зависеть от нюансов работы разных приложений, в качестве инструмента ограничимся штатными средствами Windows. В конце концов, они всегда под рукой и всем доступны, даже если кто-то на практике предпочитает другие файловые менеджеры и т. п.
Где здесь что — понятно без подписей. Характерная особенность работы без кэширования — писать данные начинаем сразу, так что скорость лимитируется именно скоростью записи на внешнее устройство. И она в любом случае оказывается более низкой, чем с использованием кэширования, причем чем быстрее интерфейс, тем больше потерь. Хотя такой жути, как при использовании NASPT, и не наблюдается. Характерный «горб» в начале графика при работе кэширования — как раз быстрое считывание информации в оперативную память. Когда памяти много, а сам копируемый файл небольшой, на этом этапе операция с точки зрения пользователя может и закончиться — система отрапортует, что процесс завершен, но продолжит запись в фоне.
Что изменится, если то же количество информации будет не в одном, а в 32 файлах? Без кэширования — ничего. С кэшированием — скорость увеличится. В младших скоростных режимах USB — до уровня их возможностей. В старшем мы всё же максимума не достигаем, поскольку на таких скоростях значимыми становятся многие факторы. Но что примечательно — режим USB 3.2 Gen2 с кэшированием почти равен режиму USB 3.2 Gen2×2 без оного, то есть не стоит бежать за топовым внешним SSD, не настроив предварительно систему. И тем более не стоит жаловаться на то, что купленный топовый SSD как-то медленно работает — может, в этом виноват вовсе не он.
Также, правда, не стоит забывать и о том, что это демонстрируемые результаты: Windows отрапортует об окончании процесса, как только последняя порция данных окажется в дисковом кэше. Физическая же запись может растянуться еще на несколько секунд. Так что если считать «по-честному», то на то может и выйти: когда речь идет о гигабайтах в секунду и десятках гигабайт оперативной памяти в современном компьютере, размер неопределенности слишком уж велик. Microsoft понять можно: по умолчанию в Windows кэширование записи включено для внутренних устройств, но выключено для внешних просто потому, что вероятность «выдергивания» первых в неподходящий момент времени близка к нулю, а для вторых — нет. Без кэширования — спокойнее. Однако если начинается сравнение демонстрируемых скоростей, нужно четко понимать, в каком именно режиме они получены. Даже если отвлечься от сложных материй, а просто перетаскивать файлы и папки в проводнике.
Наконец, вспомним про пресловутую «проблему мелочи» — вот что происходит, когда мы копируем всего-то 250 МБ, но почти в 3000 файлах. Здесь уже не важны интерфейсы, кэши, да и сами носители данных. Всё упирается в скорость, с которой этот набор может считаться с источника. А какова она — видно наглядно. К счастью, подобные задачи возникают редко — иначе прогресса внешних накопителей не было бы за ненадобностью.
Итого
Лет 30—40 назад компьютеры были простыми и бесхитростными. Программы — обычно тоже. Разобраться во всех нюансах работы что софта, что железа — больших проблем не составляло. Да и самих-то нюансов почти не было. С тех пор компьютерный мир сильно изменился, став комфортнее для пользователя, но сложнее для изучения. Однако пользовательский комфорт может внезапно исчезнуть, когда что-то пойдет не так. Например, когда данные на свежекупленный топовый SSD с заявленной скоростью до 2 ГБ/с начнут записываться вдвое медленнее. При том, что похожий SSD со скоростью как раз 1 ГБ/с стоит существенно дешевле, возникает ощущение, что где-то производители покупателя как обычно обманули. А вот кто виноват и что делать — в общем случае разобраться непросто. Например, потому что существуют и продаются устройства с поддержкой USB3 Gen2×2, но с собственной скоростью записи больших объемов данных на уровне сотен (а то и десятков) мегабайт в секунду. И с такими устройствами уже ничего не сделаешь — кроме как выкинуть и купить новое. Тут, действительно, как минимум неоправдавшиеся ожидания.
Но бывает так, что и с железом все нормально, и с программами —, а дело лишь в настройках. Кэширование записи на производительность влияет положительно, поэтому используется всеми современными операционными системами и в Windows для внутренних накопителей включено по умолчанию. Но с точки зрения возможной потери данных — опасно. Поэтому, к примеру, многие серверные SSD себя кэшировать запрещают, а для внешних накопителей та же Windows его не включает массово. Хотя, казалось бы, там SSD и там SSD, интерфейсы давно уже сопоставимой производительности, для программ всё прозрачно, но вести себя по умолчанию устройства будут по-разному. И при попытках оценить это «по-разному» в цифрах таковые тоже будут разными. При этом очень многое зависит от методов оценки: многие специализированные тестовые утилиты кэширование записи просто не используют, так что на его настройки не реагируют. Про низкоуровневые бенчмарки это было известно изначально, а сегодня мы показали, что и комплексных это касается. А далее все зависит от конкретных программных алгоритмов. К примеру, NASPT корректно ведет себя только при включенном кэшировании. Распространимо ли это на другие приложения общего, а не специального назначения? Разумеется! В конце концов, даже банальное перетаскивание файлов и папок в проводнике Windows на кэширование записи реагирует заметным образом.
Вывод простой. Если низкие скоростные показатели внешних накопителей смущают пользователя, то их можно заставить себя вести так же, как внутренние. Но нужно отдавать себе отчет в своих действиях — и во избежание проблем пользоваться безопасным отключением накопителя или его аналогами. Можно, конечно, и не пользоваться. И все будет хорошо… двадцать раз подряд, а на двадцать первый появятся битые файлы или ошибки файловой системы. Если такая перспектива пугает, то «смириться» с выбором Windows, вообще говоря, безопаснее. В этом случае можно быть уверенным, что если диалог копирования файлов с экрана исчез, то файл скопирован. Но тогда не стоит смущаться и более низкой скорости копирования. На деле же, повторимся, кэширование реализовано для повышения производительности. Что особенно важно, если внешний накопитель используется не для переноса данных, а для их непосредственной обработки, то есть оказывается частичной или полной заменой внутренним накопителям. И при таком раскладе правильнее не думать, а включать. Благо такая возможность сохранена.
Полный текст статьи читайте на iXBT
