RSS блога
Подписка
Обзор внешнего SSD диска Netac Z Slim 1Tb, или опыт - сын ошибок трудных
- Цена: $92.84 (с купонами и скидками на распродаже 11.11 обошелся в $ 63.51)
- Перейти в магазин
Вначале небольшое отступление. На распродаже 11.11 не удержался и купил внешний SSD диск Netac Z Slim 1Tb, по заявлению производителя, с NVME диском внутри (есть у меня слабость коллекционировать внешние носители информации). Получив заказанный SSD диск, решил сделать его обзор. Провел все тесты, которые считал необходимым провести, получил не очень впечатляющий результат по скоростным характеристикам и уже мысленно составлял обзор с негативным отзывом о диске, но желание понять причины медленной скорости накопителя подтолкнуло к размышлениям и в итоге привело к изменению мнения о диске. Впрочем, обо всем по порядку.
Диск упакован в фирменную запоминающуюся упаковку с надписью производителя Netac. Картинка яркая, броская, со стилизованной буквой модели диска Z.
Обратная сторона упаковки довольно неказиста, и несет информацию о технических характеристиках диска:
Тянуть время не будем, открываем упаковку, видим содержимое.
Вид спереди — сам SSD диск и переходник с Type-A на Type-C:
Вид сзади — кабель подключения с разъемом подключения Type-C и выходом Type-A, кожаный чехол для диска и инструкция:
Вот все содержимое в одном месте:
Инструкция крупным планом. Ничего особо интересного там нет.
Сам диск очень маленький, размером с обычную флешку.
С обратной стороны написаны его объем, тип и модель:
Он очень тонкий:
И легкий — чуть менее 30 грамм:
Возле разъема находится 4 крохотных синих индикатора работы, светят приятно и неярко, мигают при чтении/записи:
Вот так он выглядит в работе:
Корпус диска сделан из металла, есть надежда, что он будет хорошо отводить тепло от самого диска.
Тестирование проводил под ОС Windows 10 на ноутбуке HP, процессор i5-6200, 16 Гб памяти, SSD 480 Гб, 2 разъема USB 3.0.
Использовал родной кабель, переходник не использовал.
Подключаем наш SSD диск к ноутбуку, смотрим его свойства:
Диск уже отформатирован, файловая система exFAT, размер соответствует заявленному.
Так он виден в «Управлении дисками»:
ChipGenius не смог определить контроллер:
Flash Drive Information вообще не увидел SSD диск:
Посмотрим, что скажет Crystal Disk Info:
Видно, что диском не пользовались — всего 5 включений, из которых минимум 2 моих, 0 часов работы, 5 GB записано и прочитано — возможно, это было тестирование диска производителем.
SSD-Z дает минимум информации:
Последней надеждой определить модель контроллера была утилита smi_nvme_flash_id от уважаемого vlo, но надежды не оправдались:
Модель контроллера осталась загадкой, буду рад советам, как его идентифицировать программно, ломать диск не буду.
Upd. Утилита smi_flash_id_ata из комплекта smi_flash_id уважаемого Вадима Очкина выдала следующую информацию о внутреннем мире накопителя
Ну что ж, приступим к тестированию.
Первым делом проверю, насколько честная емкость диска, заодно и определю средние скорости чтения и записи.
Для этого воспользуюсь утилитой H2testw:
Видно, что емкость честная. Скорость чтения довольно высока, а вот скорость записи совсем не радует, на уровне хорошей флешки.
Пощупаем диск утилитой Crystal Disk Info.
Объем тестового файла 1 Гб:
Скорость чтения хороша, с записью вообще все печально.
А теперь с объемом 32 Гб:
Случайное чтение чуть просело на блоках 4к, последовательная запись слегка подросла, случайная запись упала. Скорости записи крайне печальные.
AS SSD Benchmark:
Опять скорость чтения нормальная, со скоростью записи огромные проблемы.
Начинаю думать, что я купил думать крайне неудачный SSD диск.
Anvils Storage Utilities:
Печаль моя безмерна, скорость записи пробивает дно.
Пришел черед HD tune Pro. Прогнал диск в двух режимах файл-тест, размер тестового файла в обоих случаях 100 Гб.
Сначала с произвольным шаблоном данных:
Теперь с нулевым шаблоном
Все стабильно, чуда нет — скорость чтения по прежнему хорошая, скорость записи ниже плинтуса.
Дальше уже особо без комментариев.
Тест по всему диску, чтение:
Теперь в режиме записи:
Пришел черед AIDA64. Тест Buffered Read. Скорость стабильна, чуть больше 400 МБ/с, с серьезным провалом в конце диска:
Линейное чтение. Первую половину диска скорость 400 МБ/с, процентах на 55 емкости диска скорость резко падает примерно до 110 MB/с, и больше не поднимается:
Теперь случайное чтение. Скорость стабильна, колеблется в районе 280-290 MB/с:
Посмотрим, что скажет SSD-Z.
Тест общей производительности:
Тест IOPS:
В общем, я уже собирался писать это обзор и предупредить о качестве диска. Но червячок сомнений не отпускал. Было ощущение, что я что-то сделал не так. Начал интересоваться, почему SSD такие шустрые, и тут меня осенило, почему в моих тестах так мала была скорость записи. Впрочем, опытные камрады наверняка уже все поняли, но уверен, есть и такие камрады, которые, как и я недавно, не понимают причины этого. А причина вот, на самом первом скрине, сейчас я ее выделил красным:
Краткий ликбез.
Когда файл пишется на винчестер, операционка записывает информацию о о его размещении в находящуюся на диске таблицу размещения файлов. Благодаря этому ОС знает, где находятся кластеры, в которых хранятся данные файла.
Когда пользователь удаляет файл, ОС убирает данные из таблицы размещения файлов, а само место на диске, занимаемое файлом, остается нетронутым. Когда нужно сохранить новые данные, в случае HDD, они просто пишутся поверх старых. С твердотельниками же все по-другому. Когда вы удаляете данные с диска, эти блоки помечаются свободными. При этом, данные останутся на диске, пока контроллер их не сотрет. Поэтому, когда на освободившееся место будут записываться новые данные, перед непосредственно записью контроллер должен очистить место старых, удаленных ранее, данных. То есть происходят 2 операции — очистка места и запись данных. Это занимает время. И чтобы решить эту проблему, существует команда TRIM. В момент удаления файла удаляется информация из таблицы размещения файлов и контроллеру SSD диска отправляется команда TRIM. Команда TRIM сообщает SSD-накопителю, что определенные области диска содержат не используемые больше данные и что эти данные можно удалить. Контроллер диска удалит эти данные, когда компьютер будет находиться в режиме простоя. Именно благодаря этому достигается высокая скорость записи SSD накопителя, поскольку при записи уже не нужно будет предварительно очищать удаленные данные.
Покопавшись в Интернете, я пришел к выводу, что Windows поддерживает команду TRIM только для дисков с файловой системой NTFS. Прямой информации об этом не нашел (может плохо искал), но косвенная позволила сделать такой вывод. А мой диск пришел с файловой системой exFAT, с ней я и тестировал диск. Именно поэтому была такая низкая скорость записи, потому что для этой файловой системы Windows не поддерживает команду TRIM.
SSD диск был немедленно отформатирован в файловую систему NTFS, и я приступил к тестированию, надеясь на подтверждение моих выводов и получение гораздо большей скорости записи. Запускаю тесты в том же порядке, что и ранее.
H2testw:
Скорости примерно те же, скорость записи немного выросла, в пределах статистической погрешности.
Запускаем Crystal Disk Mark. Объем тестового файла 1 Гб:
Вот оно! Скорость линейной записи выросла больше чем в 20 раз, скорость случайной записи — почти в 7 раз. Примерно такие цифры я и ожидал получить изначально. Догадка подтвердилась, при работе в ОС Windows файловая система SSD диска оказывает огромное влияние на его показатели скорости.
Crystal Disk Mark. Объем тестового файла 32 Гб:
И здесь рост скорости записи практически на порядки. Работающая команда TRIM делает свое дело.
Дальнейшие тесты тоже подтверждают значительный рос скорости записи при использовании в SSD диске файловой системы NTFS.
AS SSD Benchmark:
Похожие значения скоростных характеристик показывает и Anvils Storage Utilities. Общий индекс диска вырос вдвое, при этом показатель скорости вырос почти на порядок:
HD tune Pro, в двух режимах, файл-тест, размер тестового файла в обоих случаях 100 Гб.
Сначала с произвольным шаблоном данных:
Теперь с нулевым шаблоном:
Вот теперь скорость записи радует.
Тест по всему диску, чтение. График скорости почти прямая линия, средняя скорость почти 300 МБ/с:
Теперь в режиме записи. Средняя скорость 87,2 MБ/с. После примерно 250 Гб скорость с 225 МБ/с скачкообразно падает примерно до 40 МБ/с. Похоже на наличие некоего кэша размером около 250 Гб.
Пришел черед AIDA64. Тест Buffered Read. Скорость стабильна, чуть больше 400 МБ/с. Исчезли резкие пики провалов, которые были ранее:
Линейное чтение. График практически прямая линия, средняя скорость 411 МБ/с:
Теперь случайное чтение. Скорость упала в полтора раза, но все равно приличная и составляет почти 281 МБ/с:
SSD-Z. Тест общей производительности, значения показателей улучшились на порядки:
Тест IOPS тоже показывает значительный рост производительности:
Пощупаем диск утилитой USB Flash Benchmark:
Проверим запись на диск в Проводнике. Размер файла 16 Гб. Писал с системного SSD на тестируемый. Тест пролетел быстро, еле успевал сделать скриншоты. Скорость 280-289 МБ/с, стабильна все время записи.
Диск мне понравился, меня устраивает полностью. Как оказалось, чтобы диск раскрыл себя полностью, нужно обладать небольшими техническими познаниями. Если планируется его использование только с ПК, однозначно стоит сменить файловую систему с exFAT, которая стоит изначально, на NTFS.
Рекомендовать к покупке или отговаривать не буду, это личное дело каждого. Все тесты, которые я посчитал необходимым сделать, я сделал. Все цифры перед вами, решение принимайте сами. Цена за диск такого объема в момент покупки была одна из самых минимальных на рынке.
При тесте скорости записи по всему диску корпус грелся, но не очень сильно, руку не обжигал. Точно замерить температуру мне нечем.
На этом все, спасибо, что дочитали до конца. Надеюсь, обзор был полезен. Буду рад вашим комментариям.
Подтверждение покупки
В списке заказов с полной ценой на распродаже:
И с ценой после применения всех купонов:
И с ценой после применения всех купонов:
Диск упакован в фирменную запоминающуюся упаковку с надписью производителя Netac. Картинка яркая, броская, со стилизованной буквой модели диска Z.
Обратная сторона упаковки довольно неказиста, и несет информацию о технических характеристиках диска:
Тянуть время не будем, открываем упаковку, видим содержимое.
Вид спереди — сам SSD диск и переходник с Type-A на Type-C:
Вид сзади — кабель подключения с разъемом подключения Type-C и выходом Type-A, кожаный чехол для диска и инструкция:
Вот все содержимое в одном месте:
Инструкция крупным планом. Ничего особо интересного там нет.
Сам диск очень маленький, размером с обычную флешку.
С обратной стороны написаны его объем, тип и модель:
Он очень тонкий:
И легкий — чуть менее 30 грамм:
Возле разъема находится 4 крохотных синих индикатора работы, светят приятно и неярко, мигают при чтении/записи:
Вот так он выглядит в работе:
Корпус диска сделан из металла, есть надежда, что он будет хорошо отводить тепло от самого диска.
Общая информация об SSD диске
Тестирование проводил под ОС Windows 10 на ноутбуке HP, процессор i5-6200, 16 Гб памяти, SSD 480 Гб, 2 разъема USB 3.0.
Использовал родной кабель, переходник не использовал.
Подключаем наш SSD диск к ноутбуку, смотрим его свойства:
Диск уже отформатирован, файловая система exFAT, размер соответствует заявленному.
Так он виден в «Управлении дисками»:
ChipGenius не смог определить контроллер:
Flash Drive Information вообще не увидел SSD диск:
Посмотрим, что скажет Crystal Disk Info:
Видно, что диском не пользовались — всего 5 включений, из которых минимум 2 моих, 0 часов работы, 5 GB записано и прочитано — возможно, это было тестирование диска производителем.
SSD-Z дает минимум информации:
Последней надеждой определить модель контроллера была утилита smi_nvme_flash_id от уважаемого vlo, но надежды не оправдались:
Upd. Утилита smi_flash_id_ata из комплекта smi_flash_id уважаемого Вадима Очкина выдала следующую информацию о внутреннем мире накопителя
Ну что ж, приступим к тестированию.
Тестирование
Первым делом проверю, насколько честная емкость диска, заодно и определю средние скорости чтения и записи.
Для этого воспользуюсь утилитой H2testw:
Видно, что емкость честная. Скорость чтения довольно высока, а вот скорость записи совсем не радует, на уровне хорошей флешки.
Пощупаем диск утилитой Crystal Disk Info.
Объем тестового файла 1 Гб:
Скорость чтения хороша, с записью вообще все печально.
А теперь с объемом 32 Гб:
Случайное чтение чуть просело на блоках 4к, последовательная запись слегка подросла, случайная запись упала. Скорости записи крайне печальные.
AS SSD Benchmark:
Опять скорость чтения нормальная, со скоростью записи огромные проблемы.
Начинаю думать, что я купил думать крайне неудачный SSD диск.
Anvils Storage Utilities:
Печаль моя безмерна, скорость записи пробивает дно.
Пришел черед HD tune Pro. Прогнал диск в двух режимах файл-тест, размер тестового файла в обоих случаях 100 Гб.
Сначала с произвольным шаблоном данных:
Теперь с нулевым шаблоном
Все стабильно, чуда нет — скорость чтения по прежнему хорошая, скорость записи ниже плинтуса.
Дальше уже особо без комментариев.
Тест по всему диску, чтение:
Теперь в режиме записи:
Пришел черед AIDA64. Тест Buffered Read. Скорость стабильна, чуть больше 400 МБ/с, с серьезным провалом в конце диска:
Линейное чтение. Первую половину диска скорость 400 МБ/с, процентах на 55 емкости диска скорость резко падает примерно до 110 MB/с, и больше не поднимается:
Теперь случайное чтение. Скорость стабильна, колеблется в районе 280-290 MB/с:
Посмотрим, что скажет SSD-Z.
Тест общей производительности:
Тест IOPS:
Размышления, поиск причины
В общем, я уже собирался писать это обзор и предупредить о качестве диска. Но червячок сомнений не отпускал. Было ощущение, что я что-то сделал не так. Начал интересоваться, почему SSD такие шустрые, и тут меня осенило, почему в моих тестах так мала была скорость записи. Впрочем, опытные камрады наверняка уже все поняли, но уверен, есть и такие камрады, которые, как и я недавно, не понимают причины этого. А причина вот, на самом первом скрине, сейчас я ее выделил красным:
Краткий ликбез.
Когда файл пишется на винчестер, операционка записывает информацию о о его размещении в находящуюся на диске таблицу размещения файлов. Благодаря этому ОС знает, где находятся кластеры, в которых хранятся данные файла.
Когда пользователь удаляет файл, ОС убирает данные из таблицы размещения файлов, а само место на диске, занимаемое файлом, остается нетронутым. Когда нужно сохранить новые данные, в случае HDD, они просто пишутся поверх старых. С твердотельниками же все по-другому. Когда вы удаляете данные с диска, эти блоки помечаются свободными. При этом, данные останутся на диске, пока контроллер их не сотрет. Поэтому, когда на освободившееся место будут записываться новые данные, перед непосредственно записью контроллер должен очистить место старых, удаленных ранее, данных. То есть происходят 2 операции — очистка места и запись данных. Это занимает время. И чтобы решить эту проблему, существует команда TRIM. В момент удаления файла удаляется информация из таблицы размещения файлов и контроллеру SSD диска отправляется команда TRIM. Команда TRIM сообщает SSD-накопителю, что определенные области диска содержат не используемые больше данные и что эти данные можно удалить. Контроллер диска удалит эти данные, когда компьютер будет находиться в режиме простоя. Именно благодаря этому достигается высокая скорость записи SSD накопителя, поскольку при записи уже не нужно будет предварительно очищать удаленные данные.
Покопавшись в Интернете, я пришел к выводу, что Windows поддерживает команду TRIM только для дисков с файловой системой NTFS. Прямой информации об этом не нашел (может плохо искал), но косвенная позволила сделать такой вывод. А мой диск пришел с файловой системой exFAT, с ней я и тестировал диск. Именно поэтому была такая низкая скорость записи, потому что для этой файловой системы Windows не поддерживает команду TRIM.
Как проверить – а работает ли TRIM в ОС Windows
В запущенной от имени Администратора командной строке или PowerShell вводим команду «fsutil behavior query disabledeletenotify» без кавычек и смотрим на результат. Если в выводе значатся «0», то это хорошо – TRIM работает. Если «1», то функционал TRIM недоступен. Всё верно: ноль – включённая команда, 1 – выключенная команда.
Новое тестирование
SSD диск был немедленно отформатирован в файловую систему NTFS, и я приступил к тестированию, надеясь на подтверждение моих выводов и получение гораздо большей скорости записи. Запускаю тесты в том же порядке, что и ранее.
H2testw:
Скорости примерно те же, скорость записи немного выросла, в пределах статистической погрешности.
Запускаем Crystal Disk Mark. Объем тестового файла 1 Гб:
Вот оно! Скорость линейной записи выросла больше чем в 20 раз, скорость случайной записи — почти в 7 раз. Примерно такие цифры я и ожидал получить изначально. Догадка подтвердилась, при работе в ОС Windows файловая система SSD диска оказывает огромное влияние на его показатели скорости.
Crystal Disk Mark. Объем тестового файла 32 Гб:
И здесь рост скорости записи практически на порядки. Работающая команда TRIM делает свое дело.
Дальнейшие тесты тоже подтверждают значительный рос скорости записи при использовании в SSD диске файловой системы NTFS.
AS SSD Benchmark:
Похожие значения скоростных характеристик показывает и Anvils Storage Utilities. Общий индекс диска вырос вдвое, при этом показатель скорости вырос почти на порядок:
HD tune Pro, в двух режимах, файл-тест, размер тестового файла в обоих случаях 100 Гб.
Сначала с произвольным шаблоном данных:
Теперь с нулевым шаблоном:
Вот теперь скорость записи радует.
Тест по всему диску, чтение. График скорости почти прямая линия, средняя скорость почти 300 МБ/с:
Теперь в режиме записи. Средняя скорость 87,2 MБ/с. После примерно 250 Гб скорость с 225 МБ/с скачкообразно падает примерно до 40 МБ/с. Похоже на наличие некоего кэша размером около 250 Гб.
Пришел черед AIDA64. Тест Buffered Read. Скорость стабильна, чуть больше 400 МБ/с. Исчезли резкие пики провалов, которые были ранее:
Линейное чтение. График практически прямая линия, средняя скорость 411 МБ/с:
Теперь случайное чтение. Скорость упала в полтора раза, но все равно приличная и составляет почти 281 МБ/с:
SSD-Z. Тест общей производительности, значения показателей улучшились на порядки:
Тест IOPS тоже показывает значительный рост производительности:
Пощупаем диск утилитой USB Flash Benchmark:
Проверим запись на диск в Проводнике. Размер файла 16 Гб. Писал с системного SSD на тестируемый. Тест пролетел быстро, еле успевал сделать скриншоты. Скорость 280-289 МБ/с, стабильна все время записи.
Итоги
Диск мне понравился, меня устраивает полностью. Как оказалось, чтобы диск раскрыл себя полностью, нужно обладать небольшими техническими познаниями. Если планируется его использование только с ПК, однозначно стоит сменить файловую систему с exFAT, которая стоит изначально, на NTFS.
Рекомендовать к покупке или отговаривать не буду, это личное дело каждого. Все тесты, которые я посчитал необходимым сделать, я сделал. Все цифры перед вами, решение принимайте сами. Цена за диск такого объема в момент покупки была одна из самых минимальных на рынке.
При тесте скорости записи по всему диску корпус грелся, но не очень сильно, руку не обжигал. Точно замерить температуру мне нечем.
На этом все, спасибо, что дочитали до конца. Надеюсь, обзор был полезен. Буду рад вашим комментариям.
Самые обсуждаемые обзоры
+73 |
3577
145
|
+32 |
2825
55
|
+53 |
3769
69
|
Причем тут автобан?
> q1t1 что значит повороты (новые команды) каждые 5-10 метров.
Подробнее: Q1 — глубина очереди один, T1 — запросы отправляются только в один поток.
В этом случае latency имеет большее значение, у sata по идее оно меньше
Могу взять SATA SSD и сравнить напрямую, а затем через шнурок, но в
данный момент свободных боксов с usb 3 нет, а результаты usb2 скорее будут неинтересны.
(даже latency, т.е. отклик/время ответа, не говоря о скоростях).
Но если автобан намёк на NVME, то USB/SATA не конкуренты, как правило.
чтобы определить контроллер я запускал все доступные утилиты от vlo пока одна из них не признала диск.
диск при этом не пострадал, один раз завис — нужно было перетыкнуть.
это накопитель на микросхемах, так же как и ОЗУ, например.
Притормозите, речь была о разных ФС, а не работе напрямую.
Теоретически, может быть небольшое ускорение, если читаем 2 страницы из 1 блока, вот только это никак не связано с фрагментацией фс, диск для записи ищет свободный блок (64к, на минуточку), если такого нет — начинает чистить старые блоки и при необходимости собирать полупустые блоки в 1 полный.
А теперь идём дальше. Даже если файл записан был в 2 блока подряд, прошивка имеет такую штуку как «выравнивание износа», когда при записи новых данных контроллер может решить что вот этот блок с началом нашего файла почти новый, а остальные блоки прилично изношены, и перекинет первый блок в ячейку с сильным износом, в другую часть чипа или вообще на другой чип памяти. При этом со стороны фс не изменится НИЧЕГО.
Ну и небольшая аналогия, есть у hdd такая вещь как область для ремапа, на графиках линейного чтения их хорошо видно. Так вот, тут это основа работы, такая вот несвязанность физического адреса и адреса «на диске».
Впрочем, могу допустить что это неудачная попытка донести мысль про фрагментацию «физической» памяти, когда блоки заполнены например наполовину. И что трим в том числе собирает такие блоки в целые, очищая остальные для более быстрой записи. Да, это часть логики работы контроллера, вот только фс про них не знает. Вообще. Никогда. Это строго внутренняя кухня диска.
Про «путь из памяти во флэш» вообще какой-то бред.
и флеш тут _еще_ совершенно не причем.
и это еще последовательный обмен. но да, с qd=1.
Мы же в интернете…
это не взаимоисключающие, а ортогональные понятия.
мелкоблочный _и_ произвольный доступ можно посмотреть на скриншотах cdi/asssd. правда с фиксированным размером блока — зато как раз 4k.
и вот как раз ввиду того, что это ssd, особой разницы между тем что он последовательный или произвольный может и не быть (хотя у древних моделей она была).
а разница от размера блока — она безусловно есть. и именно на это фрагментация файловой системы влияет.
Не обращал внимания — видимо, накладные расходы на адресацию таксильно влияют. В реальности ФС читает блоками по 64КБ афаик (а если сработает кэширование — то и больше) и значения при 32 и меньше не имеют практического смысла.
При размере блока 1024..4096 это уже будет физически последовательный доступ (т.е. разница исчезает)
читать-то можно и с предвыборкой (главное не забывать обходить дефекты), хотя часть данных будут невостребованы и скорость чтения запрошенных упадет, а писать вы как собираетесь, если кластеры грубо говоря через один свободны? вот-вот.
по 64k обмен ведет через кеш nt5. современные могут поболе. но мы про фрагментацию файловой системы.
Дефекты — это уже уровень прошивки контроллера, не так ли? Скорость упадёт только если есть ограничения в скорости интерфейса диск-мост, данные/блоки на флеше и так читаются мегабайтами. Даже у ХДД падение будет незначительным, лишние 128КБ читаются за 0,5мс.
Дело не столько в технике, сколько в намерениях производителя ОС — там даже примитивнейших read ahead как правило не работает…
А я думал, про актуальность последовательного доступа маленькими блоками)
ntfs поддерживает работу с дефектами на своем уровне. так что не учитывать возможность их наличия и читать подряд без разбора нельзя.
если из лишних 128k востребована половина — значит скорость упадет вдвое. будет это лучше или хуже чтения только того, что надо, но мелким блоком — вопрос отдельный.
да причем тут некие «намеренья», я прямой вопрос задал — как вы собираетесь одним блоком писать поверх занятных кластеров.
разговор про мелкий блок начался не просто так, а с фрагментации файловой системы. которая и приводит к необходимости обмена мелким блоком.
Вы не путаете скорость работы и процент использования прочитанных данных? Так-то про любой кэш можно сказать, что 90+% в текущий момент не используется, ах, беда.
При том, что работа с диском — это большая задача, и никто её делать не будет, пока пипл хавает то, что есть. В простейшем случае — slc-кэш, в сложном — делать ФС/ОС/прикладнре с учётом оптимизации и приоритезации использования непрерывных обращений.
Первопричина всё же — фрагментация на физическом уровне, не так ли? Если накладные расходы на адресацию мелких блоков в теории можно снизить, то чтение с разных физических блоков замедляет работу принципиально.
что тут можно путать? если с диска на ограниченной скорости приходится читать вдвое больше данных чем запрошено, то полезная скорость тогось, вдвое ниже получится.
В простейшем случае — slc-кэш, в сложном — делать ФС/ОС/прикладнре с учётом оптимизации и приоритезации использования непрерывных обращений.
это уже какой-то поток сознания. ничто из перечисленного не изменит накладных расходов на обмен мелкими блоками.
Первопричина всё же — фрагментация на физическом уровне, не так ли?
никоим образом. это вы странное тащите, а речь была исключительно о фрагментации фс и ее послеждствиях, которые, как тут выше утверждалось, якобы на скорость не влияют.
SLC — изменяет, отсутствие медких блоков — изменяет.
А я думал, речь шла о последовательном и случайном доступе.
sata600 для любых современных ssd, кроме минимальных обьемов, ограничитель.
внешнему интерфейсу и системе сильно пофиг, что там внутри диска.
да и собственно вторая часть обзора — это как раз [p-]slc. график зависимости скорости от размера блока весьма характерный.
это проблемы диска. со стороны хоста совершенно пофиг последовательный он или случайный — команды одинаковые и количество их тоже.
Блок — 72 мегабайта??
Я тоже думаю, что обычная программа не может знать о физическом расположении блоков/ячеек флеша, контроллер по идее тасует их как хочет, — но всё же любая программа выдаёт нам линейные скорости, как она может это делать, не адресуя блоки строго по порядку??
самому же ssd пофиг, есть там фс или нету, если все были сектора прописаны — значит он заполнен.
nand, который позволял дописывать страницу в несколько приемов, кончился лет 15 назад. был он slc, да и то количество дозаписей было весьма ограничено.
Во-вторых, не путаем «запись нулей» и «очистку»! Нельзя сказать «очисти мне блок», можно только «запиши мне блок» и потом «теперь этот блок пуст». А когда реально чистить — решает только контроллер и никто больше. И повторю, трим это только «теперь этот блок пуст», а не «срочно почисти мне блок», не путаем себя и других!
Функция TRIM во флеше была не всегда, она довольно поздно появилась а до этого контроллер обходился как-то и без неё, стирая страницы непосредственно перед их записью. Так в любом случае перед записью ячейки отработала trim или нет она будет очищена, только на это уйдёт время не более того.
бывает что меняется ключ шифрования и ничего более. выполняется мгновенно (доли секунды). типичный пример — клиентские сандфорцы.
бывает что выполняется стирание пользовательских данных. занимает в зависимости от обьема секунды-десятки секунд. это наиболее типичный вариант.
бывает что выполняется кроме стирания еще и запись. этим баловались например старые жмикроны. занимало примерно как запись всего диска по интерфейсу.
контролировать тут особо нечего — флеш по команде стирания, если что пойдет не так, сообщает об ошибке.
возможно есть и более замороченные методы для каких-нить вояк и прочего, где есть и контроль, но в бытовухе такое — не.
равно как и странные представления о времени выполнения операций записи и стирания nand. это время ±порядок одинаковое. только за него пишется 16k, а стираются десятки мег. так что стереть весь флеш в накопителе — на 2-3 порядка быстрее, чем записать.
все — невозможно, только все внутри одного блока. занимает это миллисекунды. блоков на кристалле порядка тысячи. итого — порядка секунд. а вот параллелить между кристаллами никто не мешает, посему итоговое время для целого накопителя такое же.
даташиты на старый флеш доступны. потребление флеша при стирании весьма скромное.
освежите сведения и не путайте nand с nor.
смысла в нем много — банально проверить что флеш стирается и привести его в нормальное состояние. занимает это какие-то секунды-десятки на весь накопитель (ибо прекрасно параллелится) и это лишь небольшая часть времени выполнения всей процедуры.
к слову отчет селфтеста:
72000 секунд, да, это почти сутки. за это время прошел 61 цикл запись-чтение-стирание. на этом фон вспоминать про начальнон стирание просто смешно. хотя стоит отметить что эта операция автономная.
а производитель тут совершенно не причем.
ru.wikipedia.org/wiki/%D0%A4%D0%BB%D0%B5%D1%88-%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C
так вот, при размере блока стирания 128кб мы можем получить что 1 страница (4кб) у нас с данными, остальные помечены как пустые, но мы не можем их стереть, только блок целиком. Поэтому трим делает дефрагментацию — он переносит нашу страницу в новый блок (с другими страницами из полупустых блоков), а освободившиеся блоки стирает. Поэтому трим в том числе делает дефрагментацию.
НО. Это не имеет НИКАКОГО отношения к дефрагментации фс, со стороны фс не изменится НИЧЕГО, только обновятся внутренние таблицы диска.
если жа данные оставались нетронуты — это вызывает вопросы к работоспособности трима в данном окружении.
у самих дисков такое вспоминается только у особо древних — toshiba hg2/3, samsung pm800, фактически первое поколение с «поддержкой».
В конечном итоге все три — в мусор.
Далее после обзоров с красивыми фоточками были куплены 1шт нетак 32Г усб3.0 и через какое-то время 1шт 128Г усб3.0.
Обе не понравились (32Г валяется в тумбочке, 128Г была продана пока новая).
Больше никаких нетаков покупать не буду!
Я ни в коей мере не призываю покупать продукцию данного производителя, я просто протестировал купленный за свои кровные диск и поделился данными тестов. Стоит покупать или нет — каждый решает сам.
носители информации (флешки, диски) покупать только по месту в оффлайне с обязательной гарантией!
сша — там все выгоды даже ебея перекрываются ценой доставки, 5к товар и 5к доставка — норма.
То, что вы описали — это не проверка реальной работы TRIM, а проверка разрешения Windows использовать TRIM, если оно доступно. Иными словами, разрешение может быть дано, но TRIM всё равно будет не доступен. Для реальной проверки есть специальная утилита — TRIM check github.com/CyberShadow/trimcheck
P.S.
Не с твердотельниками вообще, а конкретно с флешем. Для оптана, которые тоже SSD, это не нужно, операция очистки у них нет, как и поддержки TRIM за полной ненадобностью.
но правда здесь прямой записи нет, контроллер дохлый, соответственно и результат ниже. но 20 тут быть все равно не должно.
А еще можно разбить напополам и один раздел в ntfs, второй в exfat и посмотреть на поведение.
То, что вы активировали TRIM и очистили страницы, что позволило включиться «SLC кешированию» значит ровным счетом «0». Как было «27», так столько и останется.
Мало ли, может кто еще не в курсе обмана с «SLC кешированием», поясню — при запросе блоков памяти вначале выделяется свободная память (это так называюется блоки NAND в терминологии производителей) и используется как 1 бит/ячейка. Это позволяет быстро стирать и так-же быстро записывать. Отсюда феноменальная скорость. Т.к. у MLC/TLC/QLC упаковка нескольких бит в ячейку, то и «SLC» получается в несколько раз меньшего размера. От свободной памяти. На чистом диске (после очистки) всё свободное, поэтому можно быстро записывать сразу 1/N объем информации («SLC кеширование»). А опосля начинаются чудеса производительности — теперь, при попытке записи, SSD уже записан =весь= и ему придется — стирать записанный ранее блок и записывать туда уже не 1 бит в ячейку, а «сколько влезет». Операция стирания под N бит надо делать четче «быстрого» стирания, поэтому процедура ведется дольше и старательнее (с особым контролем). Потом операция записи, она тоже ведется аккуратно, ведь надо не просто «кинуть», а сделать очень четко — уровней много и напряжения надо выдерживать качественно. Т.е. при записи за пределом «кеширования» начинается «цирк» с дикой просадкой скорости. На TLC это было заметно по пикам/провалам, а на QLC уже не видно — все скрывает абсурдная производительность операций с QLC ячейкой.
В результате, по мере заполнения диска «SLC кеширование» будет уменьшаться, т.к. ее величина от =свободного= места. Смотрите начало обзора, в USB варианте TRIM не проходит, а посему свободных ячеек в SSD небыло и, как итог, о «SLC кешировании» даже намеков не прозвучало. Тоже будет и на любой другой платформе (файловой системе) при полностью занятом диске. Или вы покупаете SSD, чтобы на него ничего не записывать? ;))
а никаких «отдельных» не бывает — просто блоки в некотором диапазоне номеров используются в однобитном режиме. сами по себе они ничем не отличаются от используемых в многобитном. вот правда использовать их после такого в многобитном не стоит в силу различного износа.
Опять же, если ячейка была в slc, мы обнулили блок и снова можем переключить её в tlc. Износ у каждой ячейки и так отличается от соседних, by design. Там скорее всего кодирование типа 8b10b и это позволяет отслеживать износ, хотя кто этих китайцев знает. Я флэшем занимался много лет назад и современные тонкости просто не знаю.
на самом деле предел чуть выше — современный флеш запросто имеет 105-110% от формально декларируемого двоичного обьема, если дефектов окажется не слишком много. а доступный пользователю обьем составляет не более 93% от ближайшего двоичного.
собственно именно потому получатеся не 25/33% (доступного пользователю), а на несколько больше.
на самом деле это должно называться, как проверить, не запрещено ли системе уведомлять диск об удалении файлов.
и то, что разрешено, о том, что трим работает еще не говорит.
Еспешиали фо. Дабы теперь уже вы могли ссылаться на «чьи то тесты». Раз уж вам лениво посмотреть самому.
А знаете, почему так? Потому что эта ева из той самой первой половины. Которая удаляет сразу. Но к эксфату это не имеет никакого отношения.
Не объяснять вам, как оно все работает на самом деле? Да, пожалуйста.
Когда был молодой, обижался на старших за то, что они «понятно не объясняют». А потом сам стал старшим. Есть желание разбираться? Разбирайтесь. Продирайтесь через сленг. На вас потрачено время. Чем старше становишься, тем более ценным становится этот ресурс. Нет? Нет. Ничего от этого, кроме потери времени, это даже не пост, от которого есть хоть какой-то потенциальная отдача, я не получаю. Все, что нужно для понимания — дано.
C опытом привык говорить о моделях. Конкретно эта ева отрабатывает трим очень быстро. Поэтому на ней и показал. Взял бы что-нибудь другое, получил бы диаметрально противоположный результат. В этом суть.
речь о том что кеш сбрасывают в многобитный флеш и после этого его можно на полной скорости записать и без трим тоже. а вот после кеша начнутся тормоза разной степени тяжести, в зависимости от заполнения.
на обьеме же в 1гиг тестируется кеш и там все хорошо.
Z SLim — m.2 SATA SSD
XZ — m.2 NVME SDD
Z8 — mSATA SSD
Брал такой на 500 Gb, он разборный, в отличие от Slim. Внутри действительно NVME. Греется сильно. Скорость норм.
nvme в ZX и там до 980 MB/s обещают, а этом же 480-490MB/s
Мил человек, хоть НГФФ, хоть НВМЕ, хоть что вы купите скоростного, у вас все будет упираться в скорость передачи юсб-3.0 порта.
Это касается именно внешних SSD
нвме другое дело, там на сунгах 3500мб/с норма, это даже в 20 гбит не пролезет без подрезания.
если уж хочется чего-то адекватного интерфейсу — надо брать отдельно коробку и туда какой-нить шустрый диск вроде wd sn550 терабайтного ставить. или там сунг pm981a.
Внутри моего Netac Z Slim 250GB, купленного у этого же продавца, 100% стоит SATA, так что если вы хотели именно NVMe, то лучше поищите другую модель.
У netac nvme на 2263xt, даже не phison e12
Не хочу оправдывать товар netac, мало ли что с ними может быт не так…
Но компактная оригинальная флешка samsung (usb 3.2, довольно шустрая)
была использована для активной работы в одной программой, через некоторое
время мне её дали поиграться с формулировкой «медленно пишет».
Скорость последовательной записи составила менее 2х мегабайт, чек утерян.
Было принято решение попробовать оживить, а если не получится — то по гарантии или шить самому.
После очень долгого форматирования (более 8 часов/ 256Gb) скоростные характеристики флешки вернулись в норму.
Файловая система вроде бы тоже была exfat.
если я сделаю из такого загрузочную флешку, то запустится ли она у клиента, если комп будет староват?
или например запишу фильмы, и подключу к телевизору (где тоже usb 2.0)?
терзают такие мысли, перед покупкой этого или аналогичного девайса :)
Фильм на диске тоже успешно воспроизвелся на ТВ.
Допотопные HDD в кейсах и то раза в три быстрее пишут, да даже самые дешманские флешки больших объёмов больше сотки постоянной записи дают, а тут вообще печаль печальная.
Проще тогда уж самому в кейсе собрать что-нибудь на Самсунге pm981a с Алика если уж такой форм-фактор нужен, оно хоть под пятихатку записи постоянной будет выжимать на весь объём.
Могу со своей стороны сказать одно- брать можно, но с оооочень хорошими скидками