У Windows Server 2025 додано нативну підтримку накопичувачів NVMe, наступна — Windows 11

[Scoffer]

Ekz0rcyst
Просто презентували як видатне досягнення а його якраз і немає. А щодо негативу то в інетах оно людь пише що у деяких стало повільніше. Так що у себе треба буде ще тестувати, а не бездумно тиснути.

[yurius_r]

Devianne
MSSql то хоче більше iops особливо на запис. А от IIS тому скоріш за все не холодно ні жарко.

[Scoffer]

yurius_r
MS SQL чудово кешує данні в оперативі і економно використовує пропускну спроможність диску аж до того що спроможний внятно працювати з хдд. Єдине що йому треба це швидко фіксувати логи на базі в один потік з чергою один. І все.

[Dr_Werdenhoff]

Вже є для Windows 11 25H2.

Пояснення значень:
735209102 (NativeNVMeStackForGeClient) - на відміну від сервера, це правильний параметр для Win 11. Окрім того потрібні наступні:
1853569164 (UxAccOptimization)
156965516 (Standalone_Future)

Тому необхідний запис реєстру виглядає так:

Код: Выделить всё

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]
"735209102"=dword:00000001
"1853569164"=dword:00000001
"156965516"=dword:00000001

Якщо SSD сумісні, а також використовують драйвер C:\Windows\system32\DRIVERS\nvmedisk.sys, пристрої відображатимуться в диспетчері пристроїв як Storage Devices, тобто, вони "переїдуть" з Дисків у новий розділ.
Несумісні залишаться там, де були як SCSI.
P.S. 990 Pro переведено нормально. Помітних змін не бачу.

[SergiusTheBest]

Це ганьба якась. На Linux воно працює з 2012 року.

[Scoffer]

На Linux воно працює з 2012 року.

"Працює" це дуже гучно сказано. В 2012 воно могло лише завантажитись як блочний бристрій. Але без тріма, без статистики, без паверменеджменту і т.п. Не в останню чергу тому що сама спека нвме більш-менш стабілізувалась лише десь в районі 20го року, а нові фічі тоннами завозять і досі. Це все ще сира технологія.

[SergiusTheBest]

"Працює" це дуже гучно сказано. В 2012 воно могло лише завантажитись як блочний бристрій. Але без тріма, без статистики, без паверменеджменту і т.п. Не в останню чергу тому що сама спека нвме більш-менш стабілізувалась лише десь в районі 20го року, а нові фічі тоннами завозять і досі. Це все ще сира технологія.

Не можу підтвердити чи спростувати. Але великі паралельні черги там з самого початку. Специфікації 1.0 та 1.1 вийшли в 2012, 1.3 в 2017.

[Scoffer]

SergiusTheBest
Ні. NVME 1 це 13й рік, 1.1 і 1.2 - 14й. Керуюча розробкою стандарту організація - 14й рік, до того хто в ліс, а хто по дрова. В 1.0 і 1.1 мультичерги були обмежені - по черзі завершення на ядро. Лише в 1.2 дозволили без обмежень, ну і так далі. Реально працездатне воно стало ближче до 20-21го року з 1.4. Плюс час на імплементацію спеки в драйвери.

Відправлено через 6 хвилин 11 секунд:
А щодо вінди, то вона підтримує повну сучасну їй спеку через сказі інтерфейс ще з часів 8ї вінди просто представляючись хба контролером. І поки що це мало кого хоч якось обмежує. Для десктопів продуктивності і в такій варіації за очі, а для віртуалізації здається досі немає, власне, паравіртуальних нвме драйверів, лише щось накшталт VMDirectPath з тонами обмежень, так що все одно всі сидять на старому-доброму сказі.

[SergiusTheBest]

Ні. NVME 1 це 13й рік, 1.1 і 1.2 - 14й. Керуюча розробкою стандарту організація - 14й рік, до того хто в ліс, а хто по дрова. В 1.0 і 1.1 мультичерги були обмежені - по черзі завершення на ядро. Лише в 1.2 дозволили без обмежень, ну і так далі. Реально працездатне воно стало ближче до 20-21го року з 1.4. Плюс час на імплементацію спеки в драйвери.

Дивіться. 2012 рік - з'являється NVME драйвер на Linux і він підримує мультичерги, але блочний рівень обмежений однією чергою. В 2014 рокі на блочному рівні з'являється blk-mq, що знімає обмеження, і мультичерги починать працювати. Тобто, ми говоримо про 2014 рік повноцінного впровадження мультичерг на Linux і 2025 рік на Windows. В NVME 1.2 не було змін до мультичерч. Це самі контролери в ті часи могли не реалізовувати дуже великі черги, а обмежуватися розміром 4-32.

[Scoffer]

SergiusTheBest
Дались тобі ті черги.
В 1.0-1.1 є обмеження одна Completion Queue на одне ядро. Я подивився, воно виявляється є і в 1.2. Коли його там прибрали мені далі лінь всі спеки передивлятись.
Тим часом сказі інтерфейс це не 32 глибина черги, а 256. Але я от не можу вигадати жодного притомного навантаження, котре не поїде кукухою від черги в 32+, 256+ і тим паче 64к. Цю фігню досі навіть віртуалізація не юзає, а це показник, між іншим.
Зроблено по принципу "тому що можемо". Ну є і є собі, їсти не просить, хай буде. Перш ніж об'являти революцію нехай покажуть реальний кейс де це все буде реалізовано в навантаженні, а не папугометр.

[SergiusTheBest]

є обмеження одна Completion Queue на одне ядро

Це не обмеження, а спеціально продуманий дизайн. Він дозволяє прибрати зайву комунікацію між ядрами для синхронізації та підвищує попадання в локальний кеш. Аналогічний підхід використовується з io_uring, SPDK, DPDK.

[unique-neon]

Потестив на Optane p905. Деякий профіт (приблизно 8% на запис і читання) є лише для RND4K Q1T1. Так розумію, що профіт від зменшеного оверхеду в драйвері.

[Alexsandr]

Та це для якихось ШІзонутих чи типу того. Більше сходу не можу вигадати софта, котрий не здуріє від таких довгих черг. Щоб ти розумів навіть в пересічному серверному навантаженні при черзі в 2 (два) вважається що вже щось йде не так і треба крутити якісь ручки, а на 20 - повний ахтунг.

У себя видел 50 очередь