Комментарии 96
Расскажите пожалуйста, как работает гарантия Seagate в странах СНГ, если у тебя диск есть, а бумаг на него спустя 4 года эксплуатации уже нет. Спасибо.
для обычной домашней системы уже продолжительное время более чем достаточно обычного SSD с интерфейсом SATA, путь даже он будет в формате M.2 С точки зрения обычного пользовательского опыта — браузер, ворд, игрушки, фоточки в лайтруме, редактирование видео в fullHD — достаточно типичных скоростей нормального SATA SSD в 500 МБ/с на чтение/запись. Доплата за PCIe при таком сценарии не даст существенного выигрыша.
А вот если хочется захвата и редактирования 4k, тем более в RAW кодеках и прочих профессиональных развлечений — вот там такие штуки очень приятны и нужны.
Те, кому надо, и так прекрасно знакомы с вот этой картинкой macosworld.ru/content/images/2018/10/2018-08-20-15.58.01.gif
Ну и с появлением сверхбыстрых SSD нас может ожидать изменение подхода к созданию игр. Правда не очень представляю как это будет устроено на ПК, где разброс носителей огромный и разработчикам надо бужет ровняться на всех. А на новом поколении приставок уже заявили об «непрерывном» игровом процессе «без загрузки уровней» за счёт быстрой подгрузки данных с SSD.
Из самого простейшего наглядно ощущается при активных дисковых операциях Steam/Origin/BattleNet, когда они применяют большой diff-патч для уменьшения размера загрузки обновления. В этот момент система на SATA SSD будет слегка подтормаживать, а на том же ПК, но на NVMe, даже работающем на PCIe 2.0 x2 (800 МБайт/с, самые первые материнки с M.2 на чипсетах типа Intel Z97) таких подтормаживаний не будет.
И я прав. www.intel.com/content/www/us/en/support/articles/000005967/memory-and-storage/legacy-client-ssds.html
Using an NVMe device to boot a computer system requires:
System BIOS configured to enable UEFI* version 2.3.1 and support NVMe boot
System based on an Intel® Z97 or X99 Chipset
Понятно, что программно можно завести его там… Но это будет медленно. Прям как USB 3.0 to SATA до Z97.
Часть поддержки аппаратной было и в Z87, но оно было жутко забаговано. Только Haswel Refresh это починил.
Плюс прошивку можно и не корячить, можно хоть тот-же кловер через usb прогрузить с тем-же результатом по скорости работы, но не времени загрузки. Поидее, если подпилить OpRom от 950го самса или нарисовать его на основе кода seabios можно и прочие NVMe запустить на чём угодно.
В ветке верно написали, если подпихнуть драйверы в UEFI/BIOS, то можно спокойно грузиться с «накопителя нового поколения». Никакой прямой зависимости между чипсетом и поддержкой этих накопителей нет.
А на новом поколении приставок уже заявили об «непрерывном» игровом процессе «без загрузки уровней» за счёт быстрой подгрузки данных с SSD
Помню, у меня 10 лет назад Morrowind именно так заработал после установки на систему Athlon64 4800+ со встроенной в материнскую плату видеокартой и 2 Гб оперативной памяти, причем с IDE диском. Переход между локациями определялся только по появлению надписи с ее названием в правом нижнем углу.
А на новом поколении приставок уже заявили об «непрерывном» игровом процессе «без загрузки уровней» за счёт быстрой подгрузки данных с SSD.Ну некоторые с рамдиска подгружали…
Ну тут ты не прав. Когда я переустановил домашнюю систему с SSD на SSD NVMe и поюзал скорость работы. То, возвращаться на "обычный" SSD совсем нет никакого желания.
- полная загрузка Windows 10 — 9 сек.
- скорость открытия офисных программ Word, Excel и прочее — мгновенная
Как мы вообще HDD раньше пользовались?
Сказывается вытеснение устаревшего SATA с огромной латентностью и т.д
а вы уверены про огромную латентность?
вот тут диск с sata3 на однопоточной синхронной записи выдаёт 40k IOPS (то есть ≈25μs), многие NVMe диски выдают примерно столько же (а лучшие всего в два раза меньшую задержку).
IOPS и латентность это разные вещи. Очень разные.
Вы так в этом уверены? Вообще-то они обратно пропорциональны, при тестировании с фиксированной глубиной очереди можно сказать:
IOPS × latency = depth
(я чуть-чуть утрирую, конечно, в реальной жизни задержки нельзя описать одним числом)
Но там все сложно… Впрочем не понимаю, вы сомневаетесь, что PCI Express имеет меньшую латентность? Это ж в стандарте прописано.
stackoverflow.com/questions/42661073/fio-latency-vs-btt-latency
Впрочем не понимаю, вы сомневаетесь, что PCI Express имеет меньшую латентность? Это ж в стандарте прописано.
я же привёл вам результаты тестов. запись в один поток как раз показывает задержки на шине (данные кладутся в кэш), мы имеем разницу грубо на 10 μs. не сказать, что это мало, но на типичных операциях чтения, например, с задержкой чтения из nand порядка 100 μs оно не особо заметно.
ну и практика — лучший критерий истины же. вот прямо сейчас запустил
fio --name=test1 --filename=/dev/xxx --bs=4k --iodepth=1 --numjobs=1 --rw=randread --direct=1 --runtime=20
read: IOPS=8140, BW=31.8MiB/s (33.3MB/s)(636MiB/20001msec)
clat (usec): min=17, max=63179, avg=122.18, stdev=194.23
lat (usec): min=17, max=63179, avg=122.24, stdev=194.23 read: IOPS=8306, BW=32.4MiB/s (34.0MB/s)(649MiB/20001msec)
clat (usec): min=26, max=2061, avg=119.00, stdev=21.01
lat (usec): min=26, max=2061, avg=119.05, stdev=21.01где тут sata, а где nvme?
и, заодно, можем ли по latency предсказать IOPS и наоборот?
Вроде как IOPS делается в пространстве пользователя, и учитывает overhead ОС, а латентность нет. И там их несколько видов.
Совсем без оверхеда ОС посчитать проблематично, но, пока мы говорим о десятках микросекунд, он не критичен.
Совсем без оверхеда ОС посчитать проблематично
Но можно. fio это может и неплохо. Той команды, которую вы используете, явно не достаточно. И опять таки.
SATA SSD: 150–200 us (микро, не мини)
NVMe SSD: 20–100 us
DRAM: 50 ns
www.quora.com/What-is-the-latency-to-first-byte-for-reading-from-a-NVMe-drive-compared-to-RAM
задержкой чтения из nand порядка 100 μs
Там еще DDR4 кеш. И для современной flash там меньше.
www.quora.com/What-is-the-latency-to-first-byte-for-reading-from-a-NVMe-drive-compared-to-RAM
Муж застает жену в постели с любовником. Жена оправившись от шока: — Так ты будешь верить своим бесстыжим глазам или любимой жене? ...
почему я должен верить каким-то постам в интернете, а не тем данным, которые я снимаю с реальных дисков?
Там еще DDR4 кеш.
набортный кэш практически не влияет на read latency при случайном доступе, его слишком мало (если уж на то пошло, то кэш операционки больше на порядок/порядки)
И для современной flash там меньше.
вот вы упоминали 20 μs, покажите мне хоть один NVMe накопитель (кроме Optane), который имеет такую read latency.
«The 970 EVO Plus was able to hit the highest TPS with latency much lower than any other drive we have tested to date at only a single millisecond.»
Важна методика тестирования.
С другой стороны разница в цене тоже не сильно большая и когда собираешь комп за 1.5к баксов, докинуть лишних $100 баксов за самый быстрый SSD хотя бы для системы не кажется такой уж и плохой идеей.
Зависит от предполагаемого предназначения компа. Может эти 100 баксов лучше закинуть в дополнительный объем накопителя. Взять не 512 ГБ, а 1 ТБ.
Я пока в раздумьях над сервером с NVMe SSD под PostgreSQL. Нужно много IOPS. Пока сложно всё.
Мб/сек тоже не помешают. MSSQL в моменте у меня до 11ГБ/с дает нагрузку под аналитическими запросами. Но вообще да, IOPS наше все.
а в чём разница между IOPS и Мб/сек? я всю жизнь думал, что если первое умножить на размер блока, то получим второе )))
MSSQL в моменте у меня до 11ГБ/с дает нагрузку под аналитическими запросами
эээ… а какая дисковая?
так-то да, на seqscan по большой таблице ms sql может максимум выжать, но я не знаю одиночных накопителей, которые способны отдать 11Гб/с
показавший ЕМНИП 72ГБ/с.
прямо в этой статье есть табличка с производительностью шины pcie, даже грядущий pcie5 в x16 столько не пропустит
а откуда эти данные в таком количестве берутся-то?
в чём разница между IOPS и Мб/сек?
в том, что с большим блоком ограничение по Мб/с мешает, а с маленьким блоком ограничивает IOPS. на последнее влияют глубина очереди незавершенных комманд к устройству и время завершения команды.
200000 IOPS x 512 байт = 100 Мбайт/с
50000 IOPS x 4кбайт = 200 Мбайт/с
теперь примерьте на гипотетическое устройство с 100000 IOPS и 800 Мбит/с
Я пока в раздумьях над сервером с NVMe SSD под PostgreSQL. Нужно много IOPS. Пока сложно всё.
Интелы P4610 вам в помощью. Как раз для этих целей.
Я пока в раздумьях над сервером с NVMe SSD под PostgreSQL. Нужно много IOPS. Пока сложно всё.
???
что там сложного?
вам каких IOPS нужно много?
записи в журнал?
смотрите колонку journal iops тут (если в двух словах, то любой dc-grade/с кондесаторами/ ssd, лучше nvme).
случайного чтения таблиц? любой ssd, если в много-много потоков — nvme, если совсем хорошо — optane (притом optane всех сделает уже в однопоточном чтении).
А то приходится только WD использовать.
- домашний / корпоративный пользователь одного или нескольких устройств;
- участник партнерской программы Seagate.
Регистрационные данные (ID и пароль) нужны для просмотра статуса обращения и создания новых заявок по гарантии. Гарантийный возврат может быть осуществлен только после создания заявки на сайте и ее подтверждения компанией Seagate. Если возникнут сложности с созданием заявки, то можно получить консультацию по телефону гарантийной поддержки: 8-800-555-64-13.
Зачем нужен SSD с интерфейсом PCI Express 4.0
был дан неожиданный, излагаю тезисно.
(с точки зрения стоит ли покупать именно сейчас)
— поддержка материнских плат плохая, AMD — фрагментарно, Intel — отсутствует
— перспективы поддержки туманные — три года прошло, воз и ныне там. А все потому, что видеокарты выигрыша не получают
— с выбором контроллеров совсем плохо, один только и доступен, да и тот — старый с приделанным костылем. В результате скорость шины утилизует не полностью.
(выиграю ли что-то я лично)
— на играх ничего заметного не получу — секунда на плече 10 сек при загрузке уровня
— на копировании скорость вырастет — но для этого мне надо копировать с одного такого SSD на другой — сценарий, где это мне пригодится, не ясен
— что-то туманно лучше для создателей контента, но тут я не полезу как сапожник выше сапога.
Так что по суммарной тяжести содеянного (если я прочитал правильно) — вопрос закрыт.
Можно тогда другой, чтоб 2 раза не вставать? Не могли бы в блоге Сигейт изложить официальную позицию по поводу SMR дисков? А то я вот понял, что диски Seagate мне больше рассматривать к покупке не стоит — может быть я ошибся?
Так как
— Сигейт дезинформирует своих покупателей о свойствах своей продукции, утаивая важнейшие характеристики и меняя спецификации уже выпускаемых товаров
— Не производит 2.5 диски без SMR — хотя новости о таком крупном изменении я тоже как то не увидел
— Я могу ожидать продолжения такой политики на другие товарные группы
200Мб/с в один поток блоками 4кб — это получается 50к IOPS или 20мкс.
накопители на pcie 3 выдают столько же, то есть от pcie 4 уменьшения задержек не ждать?
В некоторых тестах сливает Самсунг — 3dnews.ru/995849/pci-express-4-0-for-nvme-ssd
Можно я вам не поверю в 600к random write iops? Либо они не sustained, либо не persistent, либо вы мухлюете ещё в чём-то.
Если я сделаю fio с --fsync=1, что мы увидим на randwrite?… хоть пару тысяч iops'ов сможете?
Да ладно, никакой консьюмерский диск без PLP не выдаст на синхронщине больше 1к с копейками, ему же каждый flush надо на флешку записывать. Непрофильная для них задача. :-)
А те, для которых профильная, в угоду маркетологам стоят как чугунный мост за добавку в несколько вшивых конденсаторов.
Кстати, тут очень в помощь старенькие Optane на 16 и 32 ГБ. В slog-e такие использую, в результате на zvol-ах получается около 4-6kIOPS на синхронный 4k randwrite. И стоят копейки. Только найти их трудно уже стало.
Ну вот меня это сильно огорчает. Писали бы честно, было бы легче выбирать.
Как же тогда этим людям заявлять о красивых цифрах? Указывать на слабые места — это не продать товар. Убрать эти слабые места — это убить свои же продажи в корпоративном сегменте. Не будет здесь правды.
Та же ситуация с SMR получила огласку только в силу большого числа людей, которые набили шишки. О существовании синхронной и асинхронной записи домашний пользователь не подозревает, поэтому полагаю, что этот обман с SSD навряд ли выльется в скандал.
А первичный отбор можно осуществить просто по защите от потери питания. Если она есть — с высокой вероятностью синхронные записи будут кэшироваться на устройстве. Если защиты нет — то точно не будет такого кэша.
этот обман с SSD навряд ли выльется в скандал.
Тут особо обмана то и нет. Цифры показывают в тех условиях, в которых будет использоваться накопитель. Никакой домашних пользователь не будет отключать везде кэширование. Он не знает, да оно и не надо ему.
Обман тут в том, что заявляется о характеристике (600kIOPS), но не говориться, что проявляться она будет только в одном далеко не самом актуальном сценарии нагрузок — асинхронной случайной записи. В статье же (как и в других рекламных материалах) эта нагрузка названа случайной записью. Вообще любой случайной записью. Без каких-либо звёздочек и пояснений:
Такая нагрузка, в общем-то, чисто синтетическая. В основном, в домашнем использовании важна последовательная запись (для неё всё равно какой быть — синхронной или асинхронной) — т.е. пишем большие файлы, качаем торренты и т.п., последовательное чтение — т.е. читаем всё то же, что и в первом случае, и случайное чтение — старт ОС/ПО, подгрузка данных и т.п. В энтерпрайзе ещё важна синхронная случайная запись, то есть СУБД и прочее с ACID и похожими требованиями.
При этом нигде не говорится, что если нужно будет обеспечить целостность при случайной записи маленьких кусочков данных, то производительность модномолодежного диска провалится на дно, и заявленных характеристик покупатель не увидит. Как нигде не говорится, что он вообще нигде этих цифр не увидит, кроме как в бенчмарке.
А по поводу кэширования — вероятно, мы с Вами:
Вероятно, Вы говорите о кэше ОС. Я же говорю о кэше диска.
То кэширование, которое в диске, перенастроить невозможно, это неотъемлемая часть накопителя. Условно, в первом приближении, кэширование записи на диске позволяет накопителю отчитываться ОС об успешном завершении операции ещё до фактической записи на флешку, а также объединять в оперативной памяти диска несколько записей рядом в меньшее их количество с большим размером блока.
Сама по себе флеш-память — штука довольно медленная на запись, и нормально работает только на более-менее больших блоках данных, в связи с чем такое объединение существенно важно для адекватных показателей случайной записи.
Всё существенно меняется, когда необходимо обеспечить целостность данных.
Встаёт вопрос, как диск относится к FLUSH — операции, гарантирующей, что все предыдущие запросы на запись смогут пережить внезапное отключение питания. И в этом-то между корпоративными и пользовательскими накопителями и кроется разница.
Пользовательским накопителям не остаётся никакого выбора, кроме как фактически записать всё содержимое кэша из ОП на флеш, поскольку иначе данные из кэша будут потеряны при отключении питания. Более того, если вдаваться в детали, то они могут потерять вообще все данные в связи с потерей таблицы отображения LBA в физические блоки флеш. Эти таблицы постоянно меняются в ходе фоновой очистки блоков и выравнивания износа. То есть данные будут на чипах, но контроллер не будет знать, какому адресу они соответствуют. Но там всё чуть сложнее, по факту эту таблицу при сбое питания, как правило, можно восстановить. Например, в Самсунгах есть такой атрибут — POR Recovery Count. Он говорит о том, сколько раз такое восстановление происходило.
Корпоративные же имеют возможность сделать ход конём — на них есть конденсаторы, которые при обнаружении brown-out позволяют спокойно переписать на их заряде на флешку и кэш, и таблицу преобразования адресов. Поэтому данные накопители могут на запрос FLUSH отчитываться ОС о том, что все предыдущие записи уже в безопасности, не смотря на то, что они по факту ещё в ОЗУ. Это позволяет наконец-то увидеть те здоровенные цифры с IOPS-ами хоть где-то в реальной жизни.
В статье же (как и в других рекламных материалах) эта нагрузка названа случайной записью. Вообще любой случайной записью.
Потому что никакой другой записи случайной на виндовсе 10 человек не увидит. Никто там не флашит каждый блок на диск и не гоняет субд. Случайная запись это вон установка игр, распаковка чего либо, установка винды. Там же в табличке указаны и цифры для чтения.
При этом нигде не говорится, что если нужно будет обеспечить целостность при случайной записи маленьких кусочков данных, то производительность модномолодежного диска провалится на дно, и заявленных характеристик покупатель не увидит.
Кому это надо на домашнем ссд? Никто не заботится о целостности в этом секторе рынка. Работает как работает. В бенмарке цифры увидел, игры на секунду быстрее грузятся, все довольны.
Мне изначально непонятны вообще какие-либо упоминания субд и энтерпрайза в статье о домашнем ссд. Если кто-то желает пихать такой диск в сервер — вот он пусть и разбирается, где там асинхронные записи, сколько SLC кэша у диска и т.д. и т.п. В секторе рынка, где этот накопитель должен работать, это все не имеет значение. Тут людей устраивают диски без DRAM, о чем речь. Даже падение скорости записи при длительной записи это не особо проблема. Никто таким не занимается дома. Даже производители контента — рендерить какой-нить ролик это как раз самое то для небольшого кэша, который не успеет заполнится за это время.
А по поводу кэширования — вероятно, мы с Вами:
Да. Человек выше там о fsync упоминал. И вот таким никто дома не занимается. Все кэшируется на максимум. Побьются данные — никто горевать особо не будет.
Случайная запись это вон установка игр, распаковка чего либо
это как раз последовательное
и не гоняет субдщас в каждом браузере субд(sqlite)
Потому что никакой другой записи случайной на виндовсе 10 человек не увидит
Как бы так сказать… В спеке описана лажа, не соответствующая действительности. От того, что эту лажу большинство пользователей не обнаружит, правдивее она не станет.
Но объективно, даже пользователи сталкиваются с синхронными записями. Как во встроенных СУБД, что уже отмечали в треде, так и в случае, описанном Вами:
Случайная запись это вон установка игр, распаковка чего либо, установка винды
Не обязательно случайная, это зависит от размера блоков при записи. Для ОС — да, куча мелких файлов. А те же игры как правило имеют все свои ассеты в запакованном виде, то есть используется последовательный доступ при установке.
Но главное — установщики делают fsync, ибо установленная программа должна таковой и являться. При установке той же винды в виртуалке на Proxmox на SLOG ZFS-а прилетает несколько гигабайт записей, а они на SLOG пишутся только при регулярных fsync. Поэтому на описанном сценарии консьюмерские диски также не блещут.
Не знаю, до сих пор не видел ни одного живого применения асинхронной случайной записи. Было бы очень любопытно, если кто-то подскажет, где такие нагрузки бывают.
Ну реально, если чему-то нужно записаться случайно и быстро, то желательно это сбросить из кэша, чтобы успешно хранить. Если же это не надо хранить и давать какие-то гарантии, что запись прошла, то можно писать сразу в /dev/null, так будет ещё быстрее.
Никакой домашних пользователь не будет отключать везде кэширование.
да ну прямо так и не будет, тот же sqlite часто используется, например, он на каждый commit делает fsync. про «взрослые» sql и говорить не стоит.
сейчас глянул, даже berkeley db fsync использует, думается, что и другие key-value тоже.
1) Сколько проживут данные на этом накопителе при отсутствии питания?
2) Есть ли вариант перевода всего накопителя в псевдо-SLC режим (к примеру у SMовских контроллеров это вообще штатная штука, включаемая одним битом в прошивке)?
3) Если его можно в полностью в «SLC» перевести — то сколько там данные проживут опять-же без питания?
2) Надёжность и долговечность (к примеру гусмас 860ый у меня уже второй эксплуатируется, т.к. первый по wear leveling и used reserved block начал уходить в нирвану мёртвых ячеек) — я очень не люблю менять железо, если его параметры меня устраивают.
За счёт этого я готов мириться, что за центу 1Тб я получу 200Гб, но хочется эти 200Gb иметь с конским числом перезаписей на ячейку.
За счёт этого я готов мириться, что за центу 1Тб я получу 200Гб, но хочется эти 200Gb иметь с конским числом перезаписей на ячейку.
покупайте серверные накопители и будет вам счастье
www.youtube.com/watch?v=4DKLA7w9eeA&t=87
так в IOPS'ах отличие есть только во много-много потоков, что десктопной нагрузке не свойственно. итого остаётся более высокая скорость линейных операций, что вроде бы и неплохо, но на типичном десктопе опять же не так уж часто встречаются линейные операции таких размеров, чтобы разница с sata-накопителями стала заметна.
Ну, цена даже не столько самого девайса, сколько "обвязки", намекает, что не для 95%. А так, мне бы пригодилось для разработки, тех же БД несколько штук запустить
Контроллер умрет раньше памяти.
я про это написал чуть выше.
судя по тому, что у всех nvme (включая optane) write latency упирается в ≈20 μs, это какое-то ограничение шины pcie, и, похоже, pcie4 не решает проблему.
Правда не очень представляю как это будет устроено на ПК, где разброс носителей огромный и разработчикам надо бужет ровняться на всех. А на новом поколении приставок уже заявили об «непрерывном» игровом процессе «без загрузки уровней» за счёт быстрой подгрузки данных с SSD.
Всё просто.
Разработчики движков для игр уже подготавливают их под SSD, об этом, к примеру, уже заявил Тим Суини с его Unreal Engine.
Решают разработчики движков, а не кансоли и так было, и будет всегда.
P.S.
В игравой станции 5 будет использоваться SSD от Samsung, на самой паршивой и бюджетной QLC памяти.
Зачем нужен SSD с интерфейсом PCI Express 4.0? Объясняем на примере Seagate FireCuda 520