А конкретика есть какая-то с аргументами, что именно ухудшиться и почему, ну пусть за массивом следит VROC.

Делайте тестовый стенд и тестируйте.

А конкретика есть какая-то с аргументами, что именно ухудшиться и почему, ну пусть за массивом следит VROC.

Всем мирного неба над головой. Вопрос, есть четыре P5800x 400 GB, планируется RAID10 и вот думаю, не лучше ли в этом случае RAID делать на Intel VROC, так как я не верю что ZFS даст такую же производительность на 4к блоках, а вот сверху уже накатить ZFS в режиме single disk, чтобы пользоваться остальными сервисами ZFS.

Он и после того как вы нахуярите его поверх vroc не даст Вам такую производительность

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

И я не вижу примерно ничего про то как vroc справляется с silent corruption P.S. Наблюдаю, что они закрывают Write Hole с падением производительности и только при поддержке со стороны ОС этого, но это про другое

Мне казалось, что silent corruption это больше когда нет ECC, но так-то у VROC свои механизмы обязательно должны быть, особенно когда четыре диска (в случае двух сложнее без чексуммы)

Мне казалось, что silent corruption это больше когда нет ECC, но так-то у VROC свои механизмы обязательно должны быть, особенно когда четыре диска (в случае двух сложнее без чексуммы)

надежда - это все что есть ?

Ну как бы вероятность того, что в Интел работают не дураки и продвигают еще и эту технологию в Entherprise, дает уверенность на 95%, не меньше.

https://support.lenovo.com/jp/en/solutions/ht512368-hot-plugging-or-hot-removing-intel-nvme-drives-on-esxi-operating-system-may-cause-psod-lenovo-thinksystem https://support.lenovo.com/my/en/solutions/ht512700-thinksystem-sr630sr650-does-not-support-combination-of-esxi-and-vmdvroc-lenovo-thinkagile-and-thinksystem https://bugs.launchpad.net/bugs/1984117 https://www.reddit.com/r/esxi/comments/16uwfvr/intel_vroc_2xnvme_raid1_for_esxi_78_is_now/ Никогда ведь Интел не продвигал технологию которая никому не нужна является отличительной чертой от АМД и которая сырая

Странно слышать такой аргумент от ИТ-ка, ибо где в IT не бывает багов? В ZFS тоже недавно были, которые могли приводить к полной потере данный.

Странно слышать такой аргумент от ИТ-ка, ибо где в IT не бывает багов? В ZFS тоже недавно были, которые могли приводить к полной потере данный.

это какой?

И это обнаружили и пофиксили. Vroc фиксится через обновление UEFI, если вендор захочет выпустить прошивку после того как Интел разработает патч

Только я чет пока такого уровня багов в VROC не слышал.

Само собой, ведь технологией пользуются только для загрузки в enterprise сегменте

Технологией дофига где используются, уже до домашних материнок дошла

По контроллеру, читаем. Если считаете, что vroc = прямой доступ до дисков - если проёбете данные - Вы сами себе злой буратино https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Hardware.html#controllers

Правда? Вау.

Что-то сегодая день упоминаний vroc, проще же родимый mdadm тогда уж юзать

Ну раз «Вау» и больше ничего, то пока я прав.

Действительно, если Вы сюда пришли услышать, что "Вы правы" и "Ваше решение верное" - ждите других людей тогда

Пфф, https://www.theregister.com/AMP/2023/11/27/openzfs_2_2_0_data_corruption/

/report

/report

@gmelikov Нюанс, в Ubuntu за это отвечает пакет dkms https://manpages.ubuntu.com/manpages/focal/en/man1/dh_dkms.1.html Для 22.04 Для 23.04\24.04 dh-dkms существует https://packages.ubuntu.com/noble/kernel/dh-dkms Хм

Пока не понял тебя, слишком вырвано из контекста

ЧЯДНТ? Скачал релиз 2.2.3, сказал make deb и получил только zfs-dkms*.deb. Где остальное? дкмс мне нах не упал, мне нужен деб с модулями ядра и деб с юзерспейсными утилитами

ЧЯДНТ? Скачал релиз 2.2.3, сказал make deb и получил только zfs-dkms*.deb. Где остальное? дкмс мне нах не упал, мне нужен деб с модулями ядра и деб с юзерспейсными утилитами

native-deb-utils ещё

https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html#dkms-1

а, имеешь в виду для более старых убунт инструкция не подходит

а, имеешь в виду для более старых убунт инструкция не подходит

https://openzfs.github.io/openzfs-docs/Developer%20Resources/Building%20ZFS.html тут как-то без уточнения что make deb уже сломали и надо токо native-dev

вообще не ломали, должно также работать как и раньше

native-deb не работает: dpkg-buildpackage: error: cannot read debian/control: No such file or directory

нужен автоген еще?

типа если из гита нужный релиз слить то всё ок будет?

Народ, такой вопрос. Если я запущу стенд ресив на с хоста 1 на хост 2. Проходит синхронизация. Можно ли с хоста 2 на хост 1 запустить такой же сенд ресив, на те же данные?

Без удаления фс на приемнике, как это сделать?) может ключи какие то есть?

А ещё лучше опиши зачем тебе такое

Смотри. У меня есть сервер, откуда инфа льется на клиенты. Так случилось что на сервере фс крашнулась. Я хочу перелить с клиента живую инфу на сервер. Можно стандартно удалить фс на сервере и все зальется как надо. Но возможно есть вариант не переливать все, а перелить только то что не совпадает, и таким образом починить быстро.

если остались общие снапшоты то поверх них по идее должно позволить сделать recv, мб следующие снапы только придётся удалить

Если удалить или не удалять общие снапы, которые появляются при синке, то пишет что там уже типо место занято, синкай куда то ещё. Как я сейчас понимаю, синк делается так: сервер льет инфу клиенту, и может туда же заливать инфу путем перекачки снапов инкрементно. Но если то место куда ты указываешь для заливки занято чем то, то оно выдает ошибку и отказывается что либо делать.

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