nvmet - это nvme target. Драйвер содержит общий код реализции nvme таргета, а протоколо-специфичные вещи лежат, соответственно в nvmet-tcp, nvmet-rdma и т.д.
Скорее всего оно с обеих сторон (и инициатор, и таргет) оффлоадится в сетевую карту, так что процессор этого трафика вообще не видит. А ему уже nvmeof подсистема выдает блочные устройства.
Qemu может использовать HVF как бекенд, так что с хардварным ускорением там все хорошо. В мейлинг листах лежат арм-специфичные патчи, что позволяют запускать windows 10 на м1.
Помимо этого, на м1 уже сейчас работает tech preview parallels.
Как я понял, там сейчас другая модель: создается nvme subsystem, с каким-то номером, а дальше подсистеме соответствует один или несколько контроллеров, у которых есть неймспейсы, типа nvme14c33n1, т.е. подсистема -> номер контроллера -> номер неймспейса. Эти устройства внутри ядра слепляются через multipath в одно, которое уже видно в userspace, и называется как подсистема -> номер неймспейса, например, /dev/nvme14n1.
Насколько мне известно по рассказам ментейнеров nvme подсистемы ядра, никто не обещал, что nvme1 и nvme1n1 будет одним и тем же устройством, просто так получилось. Все сломалось, когда в nvme завезли поддержку nvme multipath, и у неймспейса внезапно могло стать два контроллера, т.е. nvme1 и nvme2 обслуживают какой-нибудь nvme3n1. Т.е. предыдущая модель сломалась, а поддерживать старое поведение для устройств с одним путем никто не стал. Изменение было очень фрустрирующим, и были планы вообще развести устройства неймспейсов и контроллеров по разным номерам, т.е. если есть /dev/nvme1, то /dev/nvmе1n1 быть не может, и наоборот. Не знаю, завезли это, в апстрим, или так и осталось в планах.
Насколько я знаю, история с перестройкой блочного стека (blk-mq) началась с nvme, т.к. там на аппаратном уровне много очередей обработки запросов, которые было сложно эффективно загрузить существующей на тот момент инфраструктурой.
В sas и sata (который в linux реализуется трансляцией из scsi -> ata) множества очередей нет, так что и профит от blk-mq будет совсем не такой, как на nvme.
Еще была отдельная история с оптимизацией некоторых драйверов sas hba под blk-mq, но руками трогать это не приходилось.
Короче, вряд ли мы увидим драматическое улучшения работы sata ssd. Да и те, кому это надо скорее перейдут на nvme.
Тут та же история, что с proxy/vpn: обойдут, кому очень надо, а большинство пойдет туда, где заморочек меньше. А мессенджер — это социалочка, выпадение куска аудитоии негативно влияет на всю сеть.
На следующем этапе удалят приложения из сторов, а это обойти несколько сложнее. Установленные версии будут работать, пока не изменится протокол, но новых пользователей будет сильно меньше.
Тут есть проблема, что в апреле прикрыли публичные обновления Java 7. Поэтому если хочется исправлений безопасности, то надо платить деньги или идти на Java 8.
Через display port подключается только один монитор, через thunderbolt можно подключить Thunderbolt монитор, в который можно воткнуть display port моник. В любом случае на новых mbp два thunderbolt порта и один HDMI, так что даже без apple thunderbolt display подключается три внешних монитора.
Из интересного, у nvme инициатора в современных ядрах есть свой multipath драйвер, который никак не связан с dm-multipath, и не требует multipathd.
nvmet - это nvme target. Драйвер содержит общий код реализции nvme таргета, а протоколо-специфичные вещи лежат, соответственно в nvmet-tcp, nvmet-rdma и т.д.
Скорее всего оно с обеих сторон (и инициатор, и таргет) оффлоадится в сетевую карту, так что процессор этого трафика вообще не видит. А ему уже nvmeof подсистема выдает блочные устройства.
Контроллер о Marvel умеет и TCP, и RoCE. Видимо, все зависит от того, что умеет клиент.
Помимо этого, на м1 уже сейчас работает tech preview parallels.
Может все-таки мегабайт? 560МБит/с — это 70МБайт/с, даже шпиндели могут больше.
Насколько мне известно по рассказам ментейнеров nvme подсистемы ядра, никто не обещал, что nvme1 и nvme1n1 будет одним и тем же устройством, просто так получилось. Все сломалось, когда в nvme завезли поддержку nvme multipath, и у неймспейса внезапно могло стать два контроллера, т.е. nvme1 и nvme2 обслуживают какой-нибудь nvme3n1. Т.е. предыдущая модель сломалась, а поддерживать старое поведение для устройств с одним путем никто не стал. Изменение было очень фрустрирующим, и были планы вообще развести устройства неймспейсов и контроллеров по разным номерам, т.е. если есть /dev/nvme1, то /dev/nvmе1n1 быть не может, и наоборот. Не знаю, завезли это, в апстрим, или так и осталось в планах.
Насколько я знаю, история с перестройкой блочного стека (blk-mq) началась с nvme, т.к. там на аппаратном уровне много очередей обработки запросов, которые было сложно эффективно загрузить существующей на тот момент инфраструктурой.
В sas и sata (который в linux реализуется трансляцией из scsi -> ata) множества очередей нет, так что и профит от blk-mq будет совсем не такой, как на nvme.
Еще была отдельная история с оптимизацией некоторых драйверов sas hba под blk-mq, но руками трогать это не приходилось.
Короче, вряд ли мы увидим драматическое улучшения работы sata ssd. Да и те, кому это надо скорее перейдут на nvme.