Обзор внешнего 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 крохотных синих индикатора работы, светят приятно и неярко, мигают при чтении/записи:

Вот так он выглядит в работе:

Корпус диска сделан из металла, есть надежда, что он будет хорошо отводить тепло от самого диска.

Общая информация об 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.
Рекомендовать к покупке или отговаривать не буду, это личное дело каждого. Все тесты, которые я посчитал необходимым сделать, я сделал. Все цифры перед вами, решение принимайте сами. Цена за диск такого объема в момент покупки была одна из самых минимальных на рынке.
При тесте скорости записи по всему диску корпус грелся, но не очень сильно, руку не обжигал. Точно замерить температуру мне нечем.
На этом все, спасибо, что дочитали до конца. Надеюсь, обзор был полезен. Буду рад вашим комментариям.
Планирую купить +19 Добавить в избранное +95 +147
+
avatar
+3
Неспроста его (диск) Нетаком назвали :-)
+
avatar
0
Ну… к полноразмерному внешнему HDD от этого производителя за почти 6 лет использования нареканий нет. Если память не изменяет, то внутри диск Toshiba. Жаль, что информацию о контроллере сабжа не удалось вытащить.

+
avatar
+3
потому что внутри WD, Seagate, Toshiba или Hitachi
+
avatar
  • Syrax
  • 14 мая 2021, 08:32
+1
Интересно, если это nmve, то какие скорости получим, если его распотрошить и поставить в положенный ему слот на матери?
+
avatar
  • Nuts_
  • 14 мая 2021, 08:35
+8
там sata — cdi об этом написал
+
avatar
  • cl3
  • 15 мая 2021, 16:45
0
Небольшой прирост скорее всего будет — у sata время отклика меньше и е, в первую очередь в q1t1.
+
avatar
0
Прирост будет уже хотя бы потому, что автор тестировал с USB3.0, который 5 Гбит/с, а SATA3 — 6 Гбит/с.
+
avatar
  • Roms
  • 15 мая 2021, 20:33
+1
Если взять оку и выехать на автобан, без разницы сколько там ограничение, 250 или 200км/ч, ока столько не сможет.
+
avatar
  • cl3
  • 16 мая 2021, 01:14
+1
Причем тут автобан?
> q1t1 что значит повороты (новые команды) каждые 5-10 метров.
Подробнее: Q1 — глубина очереди один, T1 — запросы отправляются только в один поток.
В этом случае latency имеет большее значение, у sata по идее оно меньше
Могу взять SATA SSD и сравнить напрямую, а затем через шнурок, но в
данный момент свободных боксов с usb 3 нет, а результаты usb2 скорее будут неинтересны.
(даже latency, т.е. отклик/время ответа, не говоря о скоростях).

Но если автобан намёк на NVME, то USB/SATA не конкуренты, как правило.
+
avatar
  • Roms
  • 16 мая 2021, 04:24
0
речь шла о том, что не смотря на написанное @alexanster, не важно, USB3.0 где 5 Гбит/с, или SATA3 с аж 6 Гбит/с, Ока не сможет «упереться» ни в то, ни в то ограничение.
+
avatar
+1
Ока не сможет, обозреваемый диск — упирается.
+
avatar
0
Вот только USB3/SATA — это не автобан, а максимум город/загород с 60/90, до которых она в состоянии разогнаться. Пропускную способность USB3 диск выбирает полностью, тестов в обзоре масса.
+
avatar
  • Nuts_
  • 14 мая 2021, 08:35
0
да более менее типовой результат
чтобы определить контроллер я запускал все доступные утилиты от vlo пока одна из них не признала диск.
диск при этом не пострадал, один раз завис — нужно было перетыкнуть.
+
avatar
0
Как бы TRIM тут ни при чём, если диск пуст, то и запись должна происходить без предварительной очистки блоков. Так что остаётся только влияние файловой системы на скорость записи
+
avatar
-8
+
avatar
  • aslav
  • 14 мая 2021, 09:09
0
Не понял, при чем здесь фрагментация. Поясните, пожалуйста.
+
avatar
-10
+
avatar
  • aslav
  • 14 мая 2021, 09:34
+15
Согласно общепринятому определению, твердотельники — это SSD. Откуда у них головки? Головки — они у HDD.
+
avatar
0
это не диск, так его называют только формально.
это накопитель на микросхемах, так же как и ОЗУ, например.
+
avatar
0
Господа минусаторы, если обиделись на неверно названный накопитель — извините. Суть посыла была про нюансы (ex)fat16/32 и непонимание почему то, что приводит к снижению быстродействия на «олдскульных» дисках по выводу автора обзора послужило причиной снижения перформанса на его ssd
+
avatar
  • aslav
  • 14 мая 2021, 11:53
0
Простите, а Вы точно прочитали обзор? В обзоре я объяснил снижение производительности записи тем, что в ОС Windows 10 для файловой системы exFAT не работает команда TRIM и объяснил, что делает эта команда. Никакого отношения к фрагментации команда TRIM не имеет.
+
avatar
-5
+
avatar
+10
Фрагментация никак не влияет на производительность SSD, от слова АБСОЛЮТНО. Это в природе SSD заложено. Даже более того — вы не в состоянии никак ею управлять. Нормальный контроллер SSD по своему усмотрению может начать выравнивание износа ячеек и разнести записанный на диск файл по разным углам.
+
avatar
0
Я ж с этого и начал, усомнившись в выводах.
+
avatar
0
Значит вас не правильно поняли.
+
avatar
  • zoog
  • 14 мая 2021, 13:02
-1
Чушь. В статье 10 картинок со скоростями последовательного и случайного доступа.
+
avatar
0
О, иксперты подтянулись. Научитесь отличать прямое чтение-запись непосредственно с устройства и через I/O файловой системы ОС.
+
avatar
  • zoog
  • 14 мая 2021, 13:37
0
А какая разница? Флэш как-то по-другому работать начинает?)
+
avatar
0
Появляется дополнительный посредник между флешем, а точнее между контроллером SSD и записывающей программой в виде файловой системы. Сравните скорости в CrystalDiskMark и в H2testw, чтобы понять, о чём я.
+
avatar
  • zoog
  • 14 мая 2021, 15:38
0
Алгоритмы у программ разные. Ни одна ФС не режет скорость в 2,5 раза.
+
avatar
+1
Где вы нашли 2,5 раза? Я вижу полтора. Эти две программы — чисто для примера, которые были в обзоре. Возьмите другие, которые работают через файловую систему и напрямую с диском и попробуйте найти хоть одну первого типа, которая сможет приблизиться к синтетике из второго.
+
avatar
  • zoog
  • 14 мая 2021, 16:41
0
20 и 55МБ.
Возьмите другие, которые работают через файловую систему и напрямую с диском и попробуйте найти хоть одну первого типа, которая сможет приблизиться к синтетике из второго.
Притормозите, речь была о разных ФС, а не работе напрямую.
+
avatar
0
20 и 55 — это что? Запись на забитый диск, который итак не справляется с нагрузкой? Я про вариант, где не он сам будет узким местом, а где его будет ДОПОЛНИТЕЛЬНО тормозить файловая система. Или вы уже забыли, что изначально речь шла про ФРАГМЕНТАЦИЮ файловой системы?
+
avatar
  • zoog
  • 14 мая 2021, 17:17
0
Нет, Вы говорили, что в 1м случае — ФС тормозит, в другом — нет. А я говорил — что фрагментация файлов изменяет скорость доступа в 10..50 раз. Как одно первратилось в другое — загадка, у Вас надо спросить.
+
avatar
0
Я говорил, что фрагментация файловой системы не влияет на производительность SSD. Всё остальное появилось позже как объяснение данного «удивительного» факта.
+
avatar
  • vlo
  • 14 мая 2021, 13:45
0
ну вообще-то влияет, ибо зависимость скорости от размера блока есть (да и от их взаиморасположения — тоже), а фрагментация приводит к использованию блоков меньшего размера расположенных не последовательно. флешу оно может и пофиг, а вот для пути из памяти во флеш — нет.
+
avatar
+2
В случае флэша нет никакой зависимости, система говорит «считай мне блоки 1, 100, 10000», а дальше прошивка диска ищет где эти блоки физически и читает, прошивка ничего не знает про «файл», она знает про «блок».
Теоретически, может быть небольшое ускорение, если читаем 2 страницы из 1 блока, вот только это никак не связано с фрагментацией фс, диск для записи ищет свободный блок (64к, на минуточку), если такого нет — начинает чистить старые блоки и при необходимости собирать полупустые блоки в 1 полный.
А теперь идём дальше. Даже если файл записан был в 2 блока подряд, прошивка имеет такую штуку как «выравнивание износа», когда при записи новых данных контроллер может решить что вот этот блок с началом нашего файла почти новый, а остальные блоки прилично изношены, и перекинет первый блок в ячейку с сильным износом, в другую часть чипа или вообще на другой чип памяти. При этом со стороны фс не изменится НИЧЕГО.
Ну и небольшая аналогия, есть у hdd такая вещь как область для ремапа, на графиках линейного чтения их хорошо видно. Так вот, тут это основа работы, такая вот несвязанность физического адреса и адреса «на диске».

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

Про «путь из памяти во флэш» вообще какой-то бред.
+
avatar
  • vlo
  • 14 мая 2021, 15:01
0
есть и очень простая — когда фрагментации фс нет у диска запрашивается скажем один мегабайтный блок. когда есть — в пределе для ntfs с типичным кластером — 256 по 4k с условно произвольным адресом. с какой скоростью читается то и другое можно посмотреть в тестах.
и флеш тут _еще_ совершенно не причем.
+
avatar
0
есть наглядные тесты? В несколько прогонов.
+
avatar
  • vlo
  • 14 мая 2021, 15:25
+2
скриншоты hdtune видите? нижняя гистограмма — зависимость от размера блока. куда уж нагляднее.
и это еще последовательный обмен. но да, с qd=1.
+
avatar
0
А можно на ты? А то ощущение или что меня старым пердуном считают, или что перешли на вежливые оскорбления :) «Вы, батенька...»
Мы же в интернете…
+
avatar
  • zoog
  • 14 мая 2021, 15:47
-3
Это называется «смотрим в книгу, видим фигу». Как можно не понимать разницу между мелкоблочным и последовательным доступом…
+
avatar
  • vlo
  • 14 мая 2021, 15:52
+2
это вы чего-то не понимаете — на указанном скриншоте представлен именно что мелкоблочный _и_ последовательный доступ.
это не взаимоисключающие, а ортогональные понятия.
мелкоблочный _и_ произвольный доступ можно посмотреть на скриншотах cdi/asssd. правда с фиксированным размером блока — зато как раз 4k.
и вот как раз ввиду того, что это ssd, особой разницы между тем что он последовательный или произвольный может и не быть (хотя у древних моделей она была).
а разница от размера блока — она безусловно есть. и именно на это фрагментация файловой системы влияет.
+
avatar
  • zoog
  • 14 мая 2021, 16:10
0
хм, Вы про [img]https://pic.mysku-st.ru/uploads/pictures/05/13/16/2021/04/24/0493c6.jpg[/img]?
Не обращал внимания — видимо, накладные расходы на адресацию таксильно влияют. В реальности ФС читает блоками по 64КБ афаик (а если сработает кэширование — то и больше) и значения при 32 и меньше не имеют практического смысла.

мелкоблочный _и_ произвольный доступ можно посмотреть на скриншотах cdi/asssd. правда с фиксированным размером блока — зато как раз 4k.
При размере блока 1024..4096 это уже будет физически последовательный доступ (т.е. разница исчезает)
+
avatar
  • vlo
  • 14 мая 2021, 16:15
0
скорее следующий такой же, где slc-кеш доступен.

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

по 64k обмен ведет через кеш nt5. современные могут поболе. но мы про фрагментацию файловой системы.
+
avatar
  • zoog
  • 14 мая 2021, 16:35
0
скорее следующий такой же, где slc-кеш доступен.
Это Вы про что?

читать-то можно и с предвыборкой (главное не забывать обходить дефекты), хотя часть данных будут невостребованы и скорость чтения запрошенных упадет
Дефекты — это уже уровень прошивки контроллера, не так ли? Скорость упадёт только если есть ограничения в скорости интерфейса диск-мост, данные/блоки на флеше и так читаются мегабайтами. Даже у ХДД падение будет незначительным, лишние 128КБ читаются за 0,5мс.

а писать вы как собираетесь, если кластеры грубо говоря через один свободны? вот-вот.
Дело не столько в технике, сколько в намерениях производителя ОС — там даже примитивнейших read ahead как правило не работает…

по 64k обмен ведет через кеш nt5. современные могут поболе. но мы про фрагментацию файловой системы.
А я думал, про актуальность последовательного доступа маленькими блоками)
+
avatar
  • vlo
  • 14 мая 2021, 16:48
0
там есть вторая часть обзора, после зачистки.

ntfs поддерживает работу с дефектами на своем уровне. так что не учитывать возможность их наличия и читать подряд без разбора нельзя.

если из лишних 128k востребована половина — значит скорость упадет вдвое. будет это лучше или хуже чтения только того, что надо, но мелким блоком — вопрос отдельный.

да причем тут некие «намеренья», я прямой вопрос задал — как вы собираетесь одним блоком писать поверх занятных кластеров.

разговор про мелкий блок начался не просто так, а с фрагментации файловой системы. которая и приводит к необходимости обмена мелким блоком.
+
avatar
  • zoog
  • 14 мая 2021, 17:26
-2
ntfs поддерживает работу с дефектами на своем уровне. так что не учитывать возможность их наличия и читать подряд без разбора нельзя.
Странно, Вы уверены, что НТФС работает с листами ошибок??

если из лишних 128k востребована половина — значит скорость упадет вдвое. будет это лучше или хуже чтения только того, что надо, но мелким блоком — вопрос отдельный.
Вы не путаете скорость работы и процент использования прочитанных данных? Так-то про любой кэш можно сказать, что 90+% в текущий момент не используется, ах, беда.

да причем тут некие «намеренья», я прямой вопрос задал — как вы собираетесь одним блоком писать поверх занятных кластеров.
При том, что работа с диском — это большая задача, и никто её делать не будет, пока пипл хавает то, что есть. В простейшем случае — slc-кэш, в сложном — делать ФС/ОС/прикладнре с учётом оптимизации и приоритезации использования непрерывных обращений.

разговор про мелкий блок начался не просто так, а с фрагментации файловой системы. которая и приводит к необходимости обмена мелким блоком.
Первопричина всё же — фрагментация на физическом уровне, не так ли? Если накладные расходы на адресацию мелких блоков в теории можно снизить, то чтение с разных физических блоков замедляет работу принципиально.
+
avatar
  • vlo
  • 14 мая 2021, 20:47
0
почитайте о назначении служебного файла $badclus

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

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

Первопричина всё же — фрагментация на физическом уровне, не так ли?
никоим образом. это вы странное тащите, а речь была исключительно о фрагментации фс и ее послеждствиях, которые, как тут выше утверждалось, якобы на скорость не влияют.
+
avatar
  • zoog
  • 14 мая 2021, 20:59
-1
что тут можно путать? если с диска на ограниченной скорости приходится читать вдвое больше данных чем запрошено, то полезная скорость тогось, вдвое ниже получится.
С флеша всё читается блоками, скажем, 4МБ. Нужны нам оттуда 4Б или 4МБ — разницы нет, время не изменится. Ну а внешний интерфейс уже лет 30 как не является ограничителем.

ничто из перечисленного не изменит накладных расходов на обмен мелкими блоками.
SLC — изменяет, отсутствие медких блоков — изменяет.

никоим образом
А я думал, речь шла о последовательном и случайном доступе.
+
avatar
  • vlo
  • 15 мая 2021, 05:49
+1
:facepalm: с флеша все читается страницами. которые нынче в массе 16k (изредка 8k).
sata600 для любых современных ssd, кроме минимальных обьемов, ограничитель.

внешнему интерфейсу и системе сильно пофиг, что там внутри диска.
да и собственно вторая часть обзора — это как раз [p-]slc. график зависимости скорости от размера блока весьма характерный.

это проблемы диска. со стороны хоста совершенно пофиг последовательный он или случайный — команды одинаковые и количество их тоже.
+
avatar
  • zoog
  • 15 мая 2021, 11:06
0
с флеша все читается страницами. которые нынче в массе 16k (изредка 8k).
Я слышал, читается/пишется только целый блок. Не?
+
avatar
  • vlo
  • 18 мая 2021, 13:39
+1
читается-пишется страница (ныне типично 16k). стирается блок (типично эдак 12-81M, у предмета обзора — 72M).
+
avatar
  • zoog
  • 18 мая 2021, 15:33
0
О, то есть если требуемая страница чистая, то её можно записать без танцев с бубном?
Блок — 72 мегабайта??
+
avatar
  • vlo
  • 18 мая 2021, 16:38
+1
вот только так и можно.
+
avatar
0
Фрагментация на низком уровне — это проблемы накопителя, а не ОС. Фрагментация на уровне ОС приводит к повышенному значению IOPS для накопителя, которых у него и не так уж много — одно дело запросить блок в 512М одним запросом или 10-ю запросами из-за фрагментации на уровне файловой системы, даже если физически эти данные будут лежать в линейном адресном пространстве — целых 10 IOPS из 2000 на это будет потрачено! Кажется фигня, но это фигня только в однозадачном режиме, в реальной винде в 5-10 таких потоков конкурируют друг с другом, и обычный винчестер со своими 100 IOPS-ами на мелких операциях затыкается и общая скорость падает вплоть до 200кб/сек.
+
avatar
  • zoog
  • 15 мая 2021, 15:22
0
А что значит «на уровне ОС»? Она же знает, что 10 кусков лежат последовательно, почему не взять их за один раз? Индус-триальное погромирование?
+
avatar
0
ОС видит и знает что эти части файла лежат не последовательно, соответственно так и запрашивает у накопителя. ОС не видит внутренней адресации накопителя, не видит таблицы трансляции адресов, ей не нужны ньюансы работы накопителя. Всё что ОС может это запросить данные по такому-то адресу и записать данные по такому-то адресу, а и ещё сказать что сектор по такому-то адресу больше не нужен.
+
avatar
  • zoog
  • 16 мая 2021, 01:41
-1
То есть программы-тестеры могут адресовать непрерывное пространство, а ОС — нет? При том, что программа через ОС работает.
+
avatar
0
Если файл расположен непрерывно, то в чём проблема? Но из-за фрагментации на уровне файловой системы часто это не так. Поэтому ОС видит 10 прерывающихся кусков, запрашивает их кусками…
+
avatar
  • zoog
  • 16 мая 2021, 11:41
0
ФС сама-то знает, как расположены блоки флеш-памяти? Я читал, контроллер ССД эту информацию наружу не выдаёт, вертит как хочет.
+
avatar
0
Тестовые программы могут работать не через ФС, а напрямую с диском. Та же AIDA при записи вообще удаляет все разделы с диска, о чём несколько раз предупреждает. А у HD Tune есть отдельные вкладки Benchmark и File Benchmark с разными алгоритмами работы. Что ж до вас никак не дойдёт этот простой факт.
+
avatar
  • zoog
  • 16 мая 2021, 11:39
0
То есть ОС предоставляет доступ к диску не только как к файлам, но и напрямую — с учётом расположения ячеек флеш?
+
avatar
0
ОС — нет. Тестовая программа сама лезет туда, куда ей нужно. Причём я пишу о доступе к «секторам» диска, а не ячейкам флеша. Последнее возможно только для низкоуровневых служебных программ производителя контроллера/SSD, обычные AIDA / CDM / HD Tune и т.д. об этом ничего не знают.
+
avatar
  • zoog
  • 18 мая 2021, 15:22
0
Программа работает «в обход» ОС? Я думал, не допускать подобного — одна из главных фишек современных ОС.
Я тоже думаю, что обычная программа не может знать о физическом расположении блоков/ячеек флеша, контроллер по идее тасует их как хочет, — но всё же любая программа выдаёт нам линейные скорости, как она может это делать, не адресуя блоки строго по порядку??
+
avatar
-2
Спешите видеть чудодейственную ФС БЕЗ ФРАГМЕНТАЦИИ (ну почти)
+
avatar
  • zoog
  • 14 мая 2021, 13:01
0
Но почему тогда на незаполненном (пустом, физически не подвергавшемся записи) диске такая скорость?
+
avatar
  • vlo
  • 14 мая 2021, 14:00
0
если вы про первую часть обзора — потому что диск «искаропки» был полностьью записан, но далее не очищен. т.е. пустой он был только с точки зрения файловой системы, но не массива флеша.
+
avatar
  • zoog
  • 14 мая 2021, 14:21
-2
Нет, смарт регистрирует именно к-во записанных на флеш байт. Разве что при сборке поставили уже заполненные ячейки…
+
avatar
  • vlo
  • 14 мая 2021, 14:56
0
ну смарта в части атрибутов F1/F2 я не видел, только их трактовку со стороны cdi, которая может быть неверной. но A4/A7 намекают, что записи действительно почти не было. возможно показания смарта сброшены.
+
avatar
  • zoog
  • 14 мая 2021, 15:12
0
Смарт вообще не в курсе существования ФС. Его задача — реальные (пере)записи. Сбрасывать смарт производителю незачем, а вот микросхемы (или даже кристаллы) впоолне м.б. перезаписаны при заводских тестах/форматировании (в смысле разметки/маскировки б/б).
+
avatar
  • vlo
  • 14 мая 2021, 15:18
0
флеш никакого учета циклов не ведет.
самому же ssd пофиг, есть там фс или нету, если все были сектора прописаны — значит он заполнен.
+
avatar
0
вопрос по определению этого момента. Смарт отражает, сколько было записано через контроллер. Но действительно, что мешает поставить чипы где есть блоки с нулями (см вики, нули это была запись и нужна очистка), чипы например проверялись на работоспособность, поэтому были записаны до запайки в диск. Но что мешало запустить erase после сборки?
+
avatar
  • zoog
  • 14 мая 2021, 15:34
0
Незнание этого момента. Вот Вы до этого знали о записи в новые чипы?
+
avatar
0
не интересовался никогда, но технически это возможно же.
+
avatar
  • vlo
  • 14 мая 2021, 15:55
0
записать — можно. но прочитается фигня.
nand, который позволял дописывать страницу в несколько приемов, кончился лет 15 назад. был он slc, да и то количество дозаписей было весьма ограничено.
+
avatar
0
нули, не нули… вот представьте себе первое включение контроллера. Он будет проверять каждую страницу на чистоту? на это уйдёт несколько часов времени! Поэтому, по умолчанию начисто инициализированный контроллер считает что в ячейках находится мусор и перед использованием их надо почистить(trim). Запись нулей(единиц) это ЗАПИСЬ данных, а не ОЧИСТКА ячейки.
+
avatar
0
во-первых, не несколько часов.
Во-вторых, не путаем «запись нулей» и «очистку»! Нельзя сказать «очисти мне блок», можно только «запиши мне блок» и потом «теперь этот блок пуст». А когда реально чистить — решает только контроллер и никто больше. И повторю, трим это только «теперь этот блок пуст», а не «срочно почисти мне блок», не путаем себя и других!
+
avatar
0
А сколько? Самая быстрая операция накопителя — это security erase для 1Тб она длится час-два. Чтобы контроллер убедился в чистоте каждой ячейки надо их все как минимум прочитать, конечно эта операция не ограничена интерфейсом SATA, поэтому несколько быстрее но не намного, да и сам контроллер не шибко-то быстрый скорость обмена зависит не от скорости контроллера а скорости работы DMA в контроллере, он по сути пролетающие данные и не видит. Поэтому, проверить чистоту всех ячеек он не может мгновенно, более того если он начнёт это делать то не закончит и за сутки. Поэтому проще обнулить таблицу учёта использования ячеек и считать их записанными. В первые секунды работы накопителя, он вполне сможет создать резерв заведомо чистых страниц, чтобы обеспечить работу на запись.
Функция TRIM во флеше была не всегда, она довольно поздно появилась а до этого контроллер обходился как-то и без неё, стирая страницы непосредственно перед их записью. Так в любом случае перед записью ячейки отработала trim или нет она будет очищена, только на это уйдёт время не более того.
+
avatar
  • vlo
  • 18 мая 2021, 13:49
0
реализации secure erase применительно к ssd бывают разные.

бывает что меняется ключ шифрования и ничего более. выполняется мгновенно (доли секунды). типичный пример — клиентские сандфорцы.

бывает что выполняется стирание пользовательских данных. занимает в зависимости от обьема секунды-десятки секунд. это наиболее типичный вариант.

бывает что выполняется кроме стирания еще и запись. этим баловались например старые жмикроны. занимало примерно как запись всего диска по интерфейсу.

контролировать тут особо нечего — флеш по команде стирания, если что пойдет не так, сообщает об ошибке.

возможно есть и более замороченные методы для каких-нить вояк и прочего, где есть и контроль, но в бытовухе такое — не.
+
avatar
0
Это скорее исключения. Какой накопитель не возьмёшь из типичных, читаешь время SE — никогда не видел меньше 20 минут. запись фигня, всёравно ячейку стирать надо — это наиболее долгий процесс. А из-за ограниченной энергетики невозможно стереть все ячейки сразу — из-за пикового тока перегорят шины питания на кристаллах.
+
avatar
  • vlo
  • 20 мая 2021, 15:28
0
у вас какой-то очень специфический набор «типичных накопителей». большинство бытовухи ведет себя вышеописанным мною образом.

равно как и странные представления о времени выполнения операций записи и стирания nand. это время ±порядок одинаковое. только за него пишется 16k, а стираются десятки мег. так что стереть весь флеш в накопителе — на 2-3 порядка быстрее, чем записать.

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

освежите сведения и не путайте nand с nor.
+
avatar
  • vlo
  • 18 мая 2021, 13:41
0
после первого включения нужно выполнить начальную инициализацию накопителя. т.е. проверить флеш, почитать дефекты, стереть, записать служебные структуры итп. это делается один раз на заводе.
+
avatar
0
Стирание накопителя на заводе не производится. Эта операция занимает слишком много времени и только удорожит стоимость накопителя а смысла в ней ровно НОЛЬ. Проще изначально пометить ячейки «использованными» и при первом использовании ячейки всёравно будут очищены.
+
avatar
  • vlo
  • 20 мая 2021, 15:18
0
в большинстве виденного софта для начальной инициализации страние производится. он вообще-то не для мамкиных хакеров сделан, а именно как часть производственного процесса ssd.
смысла в нем много — банально проверить что флеш стирается и привести его в нормальное состояние. занимает это какие-то секунды-десятки на весь накопитель (ибо прекрасно параллелится) и это лишь небольшая часть времени выполнения всей процедуры.

к слову отчет селфтеста:
TOSHIBA THNSNS120GBSP
MST result:
Format Version     : 4
Test State         : Not Activated
Input Offset       : 328
Current Command    : Write
Cycles Required    : 500
Cycles Complete    : 61
ElapsedTime        : 72000
StartTemperature   : 52
MaxTemperature     : 55
Grown Bad Block    : 0
Errors:
Program            : 0
Correctable RAISE  : 0
Uncorrectable RAISE: 0
Erase              : 0
Unintended Erase   : 0
Upper Page Program : 0
Lower Page Program : 0
 0_Bit :  16499867391 95.80%
 1_Bit :    701664497  4.07%
 2_Bit :     20370260  0.12%
 3_Bit :       496971
 4_Bit :        12346
 5_Bit :          467
 6_Bit :           16
 7_Bit :            5
 8_Bit :            1

72000 секунд, да, это почти сутки. за это время прошел 61 цикл запись-чтение-стирание. на этом фон вспоминать про начальнон стирание просто смешно. хотя стоит отметить что эта операция автономная.
+
avatar
  • zoog
  • 14 мая 2021, 15:34
0
Смарт не во флеше, а в контроллере)
+
avatar
  • vlo
  • 14 мая 2021, 15:47
+1
смарт — это обобщенная статистика на основе данных хранящихся во флеше.
+
avatar
  • zoog
  • 14 мая 2021, 15:57
0
Потерял предмет. Мы о чём-то спорили? Я про то, что программа учёта смарт-параметров исполняется в контроллере ЖД.
+
avatar
0
Нет. К флешу она отношения не имеет. Это статистика, но флеша она не касается — она касается выданных и выполненных команд по записи/чтению/стиранию, ошибок чтения/записи и т.д. эти данные НЕЛЬЗЯ построить по содержимому флеша, ни темболее по содержащимся в ней данным.
+
avatar
  • vlo
  • 20 мая 2021, 15:20
0
флеша она тоже запросто касается — количество записанных страниц/стертых блоков, статистичка по дефектам, статистика по уоличеству ошибок. хотя не всегда и не везде это показывается в смарте.
+
avatar
0
Она не касается флеша. Потому что задним числом по имеющимся чипам её нельзя воспроизвести. Статистика ведётся контроллером, а не чипами памяти.
+
avatar
  • vlo
  • 21 мая 2021, 04:14
0
ведется — контроллером, хранится — во флеше.
+
avatar
  • vlo
  • 14 мая 2021, 15:54
+2
впрочем похоже те тесты проводились после h2testw, который собственно и забил весь диск, а ввиду exfat он после удаления файлов остался забитым.
а производитель тут совершенно не причем.
+
avatar
  • zoog
  • 14 мая 2021, 16:12
0
Действительно, там же ещё и тест ёмкости был!
+
avatar
  • aslav
  • 14 мая 2021, 18:46
0
Вы правы, именно так все и было, h2testw был самым первым тестом. Собственно говоря, тесты в обзоре я опубликовал в хронологическом порядке.
+
avatar
0
ни при чём
+
avatar
0
Никакого отношения к фрагментации команда TRIM не имеет.
И да и нет.
ru.wikipedia.org/wiki/%D0%A4%D0%BB%D0%B5%D1%88-%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C
Стирание, запись и чтение флеш-памяти всегда происходит относительно крупными блоками разного размера, при этом размер блока стирания всегда больше, чем блок записи, а размер блока записи не меньше, чем размер блока чтения. Собственно это — характерный отличительный признак флеш-памяти по отношению к классической памяти EEPROM.

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

Например, NAND-микросхема может иметь размер стираемого блока в сотни кбайт, размер страницы записи и чтения — 4 кбайт.
так вот, при размере блока стирания 128кб мы можем получить что 1 страница (4кб) у нас с данными, остальные помечены как пустые, но мы не можем их стереть, только блок целиком. Поэтому трим делает дефрагментацию — он переносит нашу страницу в новый блок (с другими страницами из полупустых блоков), а освободившиеся блоки стирает. Поэтому трим в том числе делает дефрагментацию.
НО. Это не имеет НИКАКОГО отношения к дефрагментации фс, со стороны фс не изменится НИЧЕГО, только обновятся внутренние таблицы диска.
+
avatar
  • zoog
  • 14 мая 2021, 13:00
0
Фрагментация в нтфс идёт постоянно, см. argon.pro/windows/ntfs/fragmentation
+
avatar
  • aslav
  • 14 мая 2021, 08:58
+1
Если диск в момент теста пуст, это не означает, что он был пустым перед тестом. Соответственно, TRIM при чем.
+
avatar
0
Для этого перед тестом необходимо выполнить стирание, типа Secure erase и т.п.
+
avatar
  • aslav
  • 14 мая 2021, 09:35
0
Это понятно. Но не запускать ведь перед каждым тестом Secure erase. Эти вопросы как раз и решает TRIM.
+
avatar
0
Это только для понимания, что являлось причиной, блоки памяти не очищены или же особенности файловой системы
+
avatar
  • Shilov
  • 14 мая 2021, 10:39
0
Распространенное заблуждение. Не решает.
+
avatar
  • aslav
  • 14 мая 2021, 11:01
0
Свое мнение я обосновал в обзоре и подкрепил тестами. Хотелось бы, чтобы Вы свое мнение подкрепили чем-то весомым, например, ссылкой на техническую статью или чьи-то тесты.
+
avatar
  • Shilov
  • 14 мая 2021, 11:29
+2
Открываете русскую википедию. Находите статью трим. Читаете определение. И размышляете над разницей между фразами «можно не хранить» и «нужно удалить». Контроллер именно так себя и ведет, как написано, т.е. «ну, можно, так можно когда-нибудь может быть удалю.» Чтобы в этом убедиться, достаточно посмотреть, как ведет себя половина ссд в реальной жизни. Именно так и ведет. С кого-то из них удаленные данные невозможно восстановить через несколько секунд. А кто-то сохранит их много дней, выключений, удалений и даже форматирований. Потому что не обязан, а может. Это разное. Хотите нормальных тестов — очищайте вручную, как вам уже и сказали ранее.
+
avatar
  • aslav
  • 14 мая 2021, 12:01
0
Пожалуй, соглашусь, что есть ненулевая вероятность попытки записи в еще не очищенный контроллером блок диска. Но при практическом использовании диска альтернатив TRIM нет.
+
avatar
  • Shilov
  • 14 мая 2021, 12:09
0
См. ниже.
+
avatar
+1
Ну почему же нет? стирать ячейки непосредственно перед записью. А TRIM — это про отложенное стирание, когда время и желание есть. У накопителя(да и у операционки) в приоритете может стоять энергоэффективность, и поэтому если есть запас очищенных блоков, зачем тратить энергию на очистку блоков которые потребуются дай бог через неделю? И выполнятся операция может к примеру когда ноутбук стоит на зарядке.
+
avatar
  • vlo
  • 14 мая 2021, 13:43
0
это оно потенциально разное. но у большинства современных контроллеров/прошивок все же одинаковое. так что в частном случае и в большинстве других — решает.
+
avatar
  • Shilov
  • 14 мая 2021, 14:01
0
У меня есть привычка тестировать разное. И периодически повторять тесты. Опять пару недель назад погонял очередной ссд в разных режимах восстановления информации. После удалений, выключений, форматирований. Если бы запомнил модель — сказал бы, но не запомнил. Потому что меня интересовала не модель, а наличие до сих пор самой возможности. Что-то из свежего. Вроде крушиал. Плевать он хотел на трим. Гетдата доставала данные в каждом тесте.
+
avatar
  • vlo
  • 14 мая 2021, 14:22
+1
максимум что мне попадалось — это фоновая отработка. т.е. если диск не дергать, он уже после отработки команд трима чистит флеш еще некоторое время. например любые на phison s11, 850evo.

если жа данные оставались нетронуты — это вызывает вопросы к работоспособности трима в данном окружении.
у самих дисков такое вспоминается только у особо древних — toshiba hg2/3, samsung pm800, фактически первое поколение с «поддержкой».
+
avatar
  • Shilov
  • 14 мая 2021, 14:41
0
Вызывает, да. Но времени нет ковыряться.
+
avatar
  • zoog
  • 14 мая 2021, 13:03
0
Там в смарте написано — запись 5ГБ.
+
avatar
+8
Было куплено 3шт нетак microSDHC 32G (одна померла через несколько месяцев, вторая начала глючить, третья кое-как работает в смартфоне).
В конечном итоге все три — в мусор.

Далее после обзоров с красивыми фоточками были куплены 1шт нетак 32Г усб3.0 и через какое-то время 1шт 128Г усб3.0.
Обе не понравились (32Г валяется в тумбочке, 128Г была продана пока новая).

Больше никаких нетаков покупать не буду!
+
avatar
  • aslav
  • 14 мая 2021, 09:52
+3
Сочувствую Вашему печальному опыту и спасибо, что поделились им.
Я ни в коей мере не призываю покупать продукцию данного производителя, я просто протестировал купленный за свои кровные диск и поделился данными тестов. Стоит покупать или нет — каждый решает сам.
+
avatar
+1
Для себя сделал простой вывод:
носители информации (флешки, диски) покупать только по месту в оффлайне с обязательной гарантией!
+
avatar
+1
в данный момент… в свете последних событий таки жаба будет побеждать гарантию)
+
avatar
+1
китай по прежнему продаёт дороже чем в рф (или сравнимо). Учитываем что у них своих майнеров тьма и диски там раскупили раньше чем у нас и в европе. Но и до чии уже несколько лет цены были сравнимы, при этом без нормальной гарантии. Ну и ждать сильно дольше.
+
avatar
0
не китаем единым
+
avatar
0
ели смотреть рф и рядом, то остаётся только европа. А туда поставляется… из китая. Ну и CU уже тоже дорогой стал.
сша — там все выгоды даже ебея перекрываются ценой доставки, 5к товар и 5к доставка — норма.
+
avatar
  • axsiel
  • 14 мая 2021, 10:14
+2
Мой опыт положительный. Работает флешка на 64ГБ от Netacт вот уже года 4 в планшете. Покупал ссд на 120ГБ синий года 3 назад, до сих пор отлично работает, состояние 98%. Два SSD только уже на 240ГБ и черного цвета работают полгода без нареканий, один как переносной жесткий диск, а второй системным в ноутбуке. Покупал я их 11.11 на распродаже в оф.магазине Netac.
+
avatar
+4
по заявлению производителя, с NVME диском внутри
Специально пошёл на сайт продавца искать, действительно ли он заявлял это. На одной из иллюстраций нашёл упоминание. Я это к чему — когда я покупал в этом же магазине этот диск, я заранее знал, что там будет SATA. Возьмите не smi_nvme_flash_id, а smi_flash_id и перепроверьте. У меня она выдаёт — Controller: SM2258
Как проверить – а работает ли TRIM в ОС Windows
То, что вы описали — это не проверка реальной работы TRIM, а проверка разрешения Windows использовать TRIM, если оно доступно. Иными словами, разрешение может быть дано, но TRIM всё равно будет не доступен. Для реальной проверки есть специальная утилита — TRIM check github.com/CyberShadow/trimcheck
P.S.
С твердотельниками же все по-другому. Когда вы удаляете данные с диска, эти блоки помечаются свободными.
Не с твердотельниками вообще, а конкретно с флешем. Для оптана, которые тоже SSD, это не нужно, операция очистки у них нет, как и поддержки TRIM за полной ненадобностью.
+
avatar
  • aslav
  • 14 мая 2021, 10:26
0
Спасибо за совет, сейчас на работе, вечером попробую.
+
avatar
+1
И ещё одно — у моего диска SLC кэш примерно треть диска. У вас — 25% от общего объёма, что наводит на нехорошие подозрения, что у вас применена QLC-память. Надеюсь, что с этим я не прав.
+
avatar
+1
скорость для qlc великовата, там порядка 20мб/с норма. Хотя… если там несколько каналов, то может и QLC, и тогда привет мизерный ресурс.
+
avatar
  • vlo
  • 14 мая 2021, 13:41
0
скорость записи у 8 терабитных кристаллов qlc (более-менее любых из существующих) должна быть порядка сотни мег.
но правда здесь прямой записи нет, контроллер дохлый, соответственно и результат ниже. но 20 тут быть все равно не должно.
+
avatar
  • aslav
  • 14 мая 2021, 21:19
0
Утилита smi_flash_id_ata из комплекта smi_flash_id уважаемого Вадима Очкина определила контроллер накопителя как SM2259, обновил обзор.
+
avatar
  • aik
  • 14 мая 2021, 10:46
+2
Из интереса — форматните обратно в exfat и посмотрите на скорость работы.
+
avatar
0
А что там интересного — опять будут такие же тормоза при записи, как в начале обзора.
+
avatar
  • aik
  • 14 мая 2021, 12:18
0
Сколько продержится.
А еще можно разбить напополам и один раздел в ntfs, второй в exfat и посмотреть на поведение.
+
avatar
  • vlo
  • 14 мая 2021, 13:39
0
будут они когда-нить потом. тут все же причина в том, что диск был продан предварительно полностью прописанным (для проверки?), но не зачищеным.
+
avatar
0
Когда-нибудь потом — это после записи 250ГБ данных, когда SLC кеш опять закончится.
+
avatar
  • vlo
  • 14 мая 2021, 16:17
0
похоже я упустил предварительный прогон h2testw…
+
avatar
0
сорри не туда
+
avatar
  • u3712
  • 14 мая 2021, 11:31
0
скорость записи ниже плинтуса
Уровень плинтуса такой-же, как и в «соседнем» обзоре.
То, что вы активировали 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, чтобы на него ничего не записывать? ;))
+
avatar
+1
Не всем и не всегда нужно за раз записать полный объём диска. Поэтому SLC-кэширование — это реально работающая технология.
+
avatar
0
Использовать те же ячейки как SLC и как QLC одновременно? Очень необычное и гениальное решение, я всегда думал что там отдельно чип есть или рядом чисто SLC блок. Но тогда это очень многое объясняет.
+
avatar
  • vlo
  • 14 мая 2021, 13:36
0
когда кеш на весь обьем (т.е. ~1/4 для qlc) — других вариантов быть и не может. у sm2258/9xt в юольшинстве случаев так.
а никаких «отдельных» не бывает — просто блоки в некотором диапазоне номеров используются в однобитном режиме. сами по себе они ничем не отличаются от используемых в многобитном. вот правда использовать их после такого в многобитном не стоит в силу различного износа.
+
avatar
-1
если часть именно QLC ячеек используется как SLC — то мы теряем ёмкость, то есть для 1тб диска четверть уходит под кэш, это 250 гиг, а теперь за счёт 1 бита вместо 4 опять делим на 4, получаем около 70 гб. Если там чисто qlc то мы вынуждены ставить уже 1тб данные + 1тб tlc-as-slc. 750+70гб = 820, вообще не похоже на правду, там 900+ должно выйти. Не сходится. Нам нужно 250*4=1тб qlc флэша, чтобы получить 250 гб. Если у нас чип (просто 2 чипа в 1 корпусе или чип с областями qlc + slc) увеличенной ёмкости, то ставим 2 по 512гб и всё.

Опять же, если ячейка была в slc, мы обнулили блок и снова можем переключить её в tlc. Износ у каждой ячейки и так отличается от соседних, by design. Там скорее всего кодирование типа 8b10b и это позволяет отслеживать износ, хотя кто этих китайцев знает. Я флэшем занимался много лет назад и современные тонкости просто не знаю.
+
avatar
  • vlo
  • 14 мая 2021, 15:23
+1
еще раз — никаких «slc-only областей» не бывает. кеш бывает или небольшой фиксированный — в выделенном наборе блоков, или на весь обьем — как здесь, и тогда все блоки используются в обоих режимах. бывают промежуточные варианты, когда часть всегда под кеш, остальное в смешанном режиме. сам современный флеш позволяет любой блок использовать в любом режиме независимо от соседних…
+
avatar
0
то есть при занятости 80% диска кэш будет не более (100-80)/4=5%?
+
avatar
  • vlo
  • 14 мая 2021, 16:01
0
именно так. но это именно верхний предел — контроллер может не переписывать кеш в многобитный массив, или переписывать в ограниченных количествах после превышения какого-то не вполне очевидного порога (именно так обычно сейчас и делают).

на самом деле предел чуть выше — современный флеш запросто имеет 105-110% от формально декларируемого двоичного обьема, если дефектов окажется не слишком много. а доступный пользователю обьем составляет не более 93% от ближайшего двоичного.
собственно именно потому получатеся не 25/33% (доступного пользователю), а на несколько больше.
+
avatar
  • u3712
  • 14 мая 2021, 17:30
0
А при занятости 100% его вообще не будет, см. начало обзора (про USB).
+
avatar
  • vlo
  • 14 мая 2021, 20:40
0
это опять же частный случай и не самый распространенный. достаточно часто все же немного будет.
+
avatar
-1
Это вынужденное решение, негативно влияющее на производительность, надёжность и ресурс памяти.
+
avatar
  • vlo
  • 14 мая 2021, 20:50
0
на производительность оно влияет как раз положительно. но не всегда.
+
avatar
  • vlo
  • 14 мая 2021, 11:50
+2
Как проверить – а работает ли TRIM в ОС Windows
на самом деле это должно называться, как проверить, не запрещено ли системе уведомлять диск об удалении файлов.
и то, что разрешено, о том, что трим работает еще не говорит.
+
avatar
  • aslav
  • 14 мая 2021, 12:08
-1
Технически Вы абсолютно правы. Я написал по-простому, по-житейски ))
+
avatar
+1
И оказались неправы технически. Потому что отсутствие запрета не равно работе TRIM.
+
avatar
  • Shilov
  • 14 мая 2021, 12:09
+1
Да, и с эксфатом у вас то же самое, что и с тримом. Т.е. плохо. Вот вам прогон диск марка на забитой информацией перед форматирование в эксфат еве:



Еспешиали фо. Дабы теперь уже вы могли ссылаться на «чьи то тесты». Раз уж вам лениво посмотреть самому.

А знаете, почему так? Потому что эта ева из той самой первой половины. Которая удаляет сразу. Но к эксфату это не имеет никакого отношения.
+
avatar
  • Shilov
  • 14 мая 2021, 13:08
+1
Стесняюсь спросить. Минисующие. Вы минусуете, простите, что? Сомневаетесь, что тс не знает, как работает трим? Ну, так не знает. В коментах выше я ему объясняю. Почитайте. Сомневаетесь, что тс не знает, что дело не в эксфате? Ну, так не знает. И нашелся человек, который не поленился, потратил свое время, и сделал для вас тест с понятной картинкой на эксфате, на таком же объеме, на до этого забитом данными диске. Т.е. сэмулировал ситуацию максимально. И специально выложил под топовым, чтобы вам не пришлось искать комент в ветках.

Не объяснять вам, как оно все работает на самом деле? Да, пожалуйста.
+
avatar
0
Я не минусил, но мне тяжело читать ваш сленг, надо применять усилия чтобы понять, что же вы хотели сказать. Вам так западло писать нормальные названия модели диска, не коверкать слова, переключаться на английский язык?
+
avatar
  • Shilov
  • 14 мая 2021, 13:46
-6
+
avatar
0
ну вот кому-то такая позиция не понравилась и он поставил минус. А может и не поэтому, я всего лишь предположил одну из возможных причин
+
avatar
  • Shilov
  • 14 мая 2021, 14:25
0
Согласен, вариант.
+
avatar
  • Z2K
  • 14 мая 2021, 16:03
+1
«Есть желание разбираться? Разбирайтесь.»
— разбираться в Ваших комментах бесполезная потеря времени, как и написание Вами этих неразоборчивых комментов.
+
avatar
  • Shilov
  • 14 мая 2021, 17:03
0
Не вопрос.
+
avatar
  • vlo
  • 14 мая 2021, 13:31
0
сунги имеют привычку высвобождать фиксированную часть slc-кеша. совершенно независимо от трим. то, что от трим зависит у них начинается за пределами кеша.
+
avatar
  • Shilov
  • 14 мая 2021, 13:48
0
«сунги имеют привычку»

C опытом привык говорить о моделях. Конкретно эта ева отрабатывает трим очень быстро. Поэтому на ней и показал. Взял бы что-нибудь другое, получил бы диаметрально противоположный результат. В этом суть.
+
avatar
  • vlo
  • 14 мая 2021, 13:58
0
любые сунги с slc-кешем.
+
avatar
  • Shilov
  • 14 мая 2021, 14:04
0
Мне лень гонять гетдату на терабайте. Но сомневаюсь, что найдет хоть что-то. Ни разу не находила. Можно потыкаться вручную диск эдитором, но тоже лень. Диск не мой, просил.
+
avatar
  • vlo
  • 14 мая 2021, 14:26
0
а причем тут сохранность данных?
речь о том что кеш сбрасывают в многобитный флеш и после этого его можно на полной скорости записать и без трим тоже. а вот после кеша начнутся тормоза разной степени тяжести, в зависимости от заполнения.
на обьеме же в 1гиг тестируется кеш и там все хорошо.
+
avatar
  • Shilov
  • 14 мая 2021, 14:45
0
Мы с тсом общались немного про другое. На самом деле я погонял гетдату не по всему объему, но существенно больше, чем гиг. Все было пустое. Т.е. либо трим отработал, либо контроллер настолько умный.
+
avatar
  • EKrava
  • 14 мая 2021, 12:31
0
насколько я помню распределение внутренностей было таким по сериям
Z SLim — m.2 SATA SSD
XZ — m.2 NVME SDD
Z8 — mSATA SSD
+
avatar
  • aslav
  • 14 мая 2021, 13:44
0
Вот надпись NVME Z Slim на картинке продавца
+
avatar
  • EKrava
  • 14 мая 2021, 13:59
0
эта картинка есть только .ru версии сайта. в eng нету.
+
avatar
+1
Только не XZ, а ZX.
Брал такой на 500 Gb, он разборный, в отличие от Slim. Внутри действительно NVME. Греется сильно. Скорость норм.
+
avatar
  • zoog
  • 14 мая 2021, 12:46
0
Некрасиво говорить «твердотельный привод диск».
+
avatar
+1
Спасибо за обзор, очень вовремя. Вот только вчера присматривал внешние SSD, и именно этот положил в Избранное. Продавец обещает скорость до 1000 МБ/с, это значит, что внутри должен быть NVMe. Но ни в одном отзыве не увидел этого. А Ваш обзор подтверждает моё сомнение, и внутри обычный NGFF. Вот теперь задумался. Плюсик поставил.
+
avatar
  • EKrava
  • 14 мая 2021, 14:03
0
именно в z slim?
nvme в ZX и там до 980 MB/s обещают, а этом же 480-490MB/s
+
avatar
+1
Не сдержался, зашел на сайт, чтоб прокомментировать.
Мил человек, хоть НГФФ, хоть НВМЕ, хоть что вы купите скоростного, у вас все будет упираться в скорость передачи юсб-3.0 порта.
Это касается именно внешних SSD
+
avatar
0
не хочу вспминать нюансы с 3.1 и 3.2, короче есть версия 5 гбит, есть 10 гбит, и вроде есть 20 гбит уже. Так вот, сата это 500мб/с реальных, то есть 5 гбит, уже подходим к сата лимиту. С 10гбит — усб уже вообще не ограничивает.
нвме другое дело, там на сунгах 3500мб/с норма, это даже в 20 гбит не пролезет без подрезания.
+
avatar
0
Это понятно. Но если нужен именно NVMe, значит, есть возможность использовать его на полную катушку. К сожалению, у ТС наверное, нет возможности прогнать данный диск через USB 3.1.
+
avatar
  • vlo
  • 14 мая 2021, 17:09
+2
«полная катушка» для типичного внешнего диска на 2263xt (а именно на нем очень любят делать дешевые экземпляры) это мег 100-200 записи после заполнения кеша.
если уж хочется чего-то адекватного интерфейсу — надо брать отдельно коробку и туда какой-нить шустрый диск вроде wd sn550 терабайтного ставить. или там сунг pm981a.
+
avatar
  • aslav
  • 14 мая 2021, 18:53
0
Вы правы, прогнать тесты через USB 3.2 не имею технической возможности.
+
avatar
0
NGFF — это рабочее название M.2, использовавшееся при разработке стандарта — всего лишь разъём, который может быть как NVMe, так и SATA.
Внутри моего Netac Z Slim 250GB, купленного у этого же продавца, 100% стоит SATA, так что если вы хотели именно NVMe, то лучше поищите другую модель.
+
avatar
0
Теперь уж точно буду другую модель присматривать. У этого же продавца есть неплохие NVMe, только для него надо будет кейс соответствующий, который стоит от 1000 руб. Если брать отдельно, то выйдет дороже обозреваемого диска.
+
avatar
  • EKrava
  • 14 мая 2021, 18:37
0
Неплохие nvme это какие?
У netac nvme на 2263xt, даже не phison e12
+
avatar
0
Хотел ссылку дать, а на Али технические неполадки. На десктопе недоступен. Мобильное приложение работает.
+
avatar
  • aslav
  • 14 мая 2021, 18:55
0
Рад, что обзор был Вам полезен, значит, не зря писал.
+
avatar
  • sdfpro
  • 14 мая 2021, 22:59
0
netac на данный момент не оч производитель. в сад ставят память предназначенную для флэшек. недавно брал микро сд, так та кончилась пережив только одну полную перезапись, начала сильно тормозить на запись, память полное г. в ссд ставят тоже по всей видимости шлак…
+
avatar
  • cl3
  • 16 мая 2021, 01:56
0
Может тут как у автора было дело в файловой системе?
Не хочу оправдывать товар netac, мало ли что с ними может быт не так…

Но компактная оригинальная флешка samsung (usb 3.2, довольно шустрая)
была использована для активной работы в одной программой, через некоторое
время мне её дали поиграться с формулировкой «медленно пишет».
Скорость последовательной записи составила менее 2х мегабайт, чек утерян.
Было принято решение попробовать оживить, а если не получится — то по гарантии или шить самому.
После очень долгого форматирования (более 8 часов/ 256Gb) скоростные характеристики флешки вернулись в норму.
Файловая система вроде бы тоже была exfat.
+
avatar
0
Вопрос к автору: вы вставляли и тестировали его в usb 3.0 (что и логично), но будет ли он работать на usb 2.0?

если я сделаю из такого загрузочную флешку, то запустится ли она у клиента, если комп будет староват?
или например запишу фильмы, и подключу к телевизору (где тоже usb 2.0)?

терзают такие мысли, перед покупкой этого или аналогичного девайса :)
+
avatar
  • aslav
  • 15 мая 2021, 21:29
0
Могу записать фильм и попробовать воспроизвести на телеке 2011 года, устроит вас такой эксперимент?
+
avatar
0
Интерфейсы вроде же обратно совместимы, разница только в скорости. Оно и на USB1.0 работать будет, только скорость… работы дисковода на гибких магнитных дисках(помнит кто ещё?). Такое бывает и на USB 2.0 когда подтяжка порта со стороны «флешки» не контачит, хост думает что подключен девайс по спецификации 1.0 и работает на соответствующей скорости…
+
avatar
  • aslav
  • 16 мая 2021, 15:28
0
Записал загрузочный образ Win10 от Strelec на диск и успешно загрузился через порт USB2.0.
Фильм на диске тоже успешно воспроизвелся на ТВ.
+
avatar
0
Диск конечно отстой, на некоторые флешки скорость записи больше. Зачем он?
+
avatar
0
Зачем он?
Тоже непонятно зачем сиё чудо вообще покупать. Абсолютно бесполезное как со стороны рабочего диска так как медленнее даже китайских флешек, так и хранения так как проще уж жёсткий в кейс запихнуть на пару терабайт.
Допотопные HDD в кейсах и то раза в три быстрее пишут, да даже самые дешманские флешки больших объёмов больше сотки постоянной записи дают, а тут вообще печаль печальная.
Проще тогда уж самому в кейсе собрать что-нибудь на Самсунге pm981a с Алика если уж такой форм-фактор нужен, оно хоть под пятихатку записи постоянной будет выжимать на весь объём.
+
avatar
0
Этот ССД 1 — меньше, чем ХДД, 2 — легче, 3 — не боится падений. А если не писать сразу большие объемы, то развивает адекватные скорости. За свою цену покупателя найдет например для бакапов, а в качестве системного его никто использовать и не предлагает.
+
avatar
0
250 такой же взял в прошлом году. Скоростные характеристики такие же, толку от NVME маловато
Могу со своей стороны сказать одно- брать можно, но с оооочень хорошими скидками