1. Forum
  2. FidoNet Russia
  3. RU.UNIX.BSD

  • главное ничего не чинить!

    From Alex Korchmar@2:5020/400 to All on Thu Aug 31 09:03:52 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>


    Хозяйке на заметку: https://www.truenas.com/community/threads/unmap-failed.85345/ https://forums.freebsd.org/threads/zfs-unmap-and-vmware-esxi-troubles.77648/ https://forum.netgate.com/topic/167882/scsi-error-on-vm

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

    Hу не выяснять же ж на самом деле, что сломалось.

    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)
  • From Eugene Grosbein@2:5006/1 to Alex Korchmar on Fri Sep 1 10:10:37 2023
    31 авг. 2023, четверг, в 09:03 NOVT, Alex Korchmar написал(а):

    Хозяйке на заметку: https://www.truenas.com/community/threads/unmap-failed.85345/ https://forums.freebsd.org/threads/zfs-unmap-and-vmware-esxi-troubles.77648/
    https://forum.netgate.com/topic/167882/scsi-error-on-vm
    что сделали генитальные разработчики freebsd по этому поводу?
    Правильно - забили х-й.
    Hу не выяснять же ж на самом деле, что сломалось.

    Во-первых, первое и третье вообще не репорты в FreeBSD.
    А второе это обмен опытом между юзерами FreeBSD, а не Problem Report
    для разработчиков в багзиллу.

    Во-вторых, UNMAP failed это ошибка, которую (виртуализированное) железо
    выдаёт драйверу в ответ на его команду SCSI UNMAP и сделать с этим драйвер особо ничего не может. Это тащем-то надо репортить разработчикам гипервизора и/или искать ответ в их Knowledge base.

    Максимум, что может сделать гостевая OS в таком случае, это попытаться
    найти workaround. В случае da0 для этого у нас есть подсистема CAM
    и man 4 da:

    kern.cam.da.X.delete_method
    This variable specifies method to handle BIO_DELETE requests:

    ATA_TRIM ATA TRIM via ATA COMMAND PASS THROUGH command,
    UNMAP UNMAP command,
    WS16 WRITE SAME(16) command with UNMAP flag,
    WS10 WRITE SAME(10) command with UNMAP flag,
    ZERO WRITE SAME(10) command without UNMAP flag,
    DISABLE disable BIO_DELETE support.

    А ещё вместо эмуляции аппаратного контроллера LSI Logic
    нынче полезно отдавать виртуалке носитель в виде VirtIO block device
    или NVMe, для последнего есть драйвер nda(4) с настройками kern.cam.da.enable_biospeedup, kern.cam.nda.max_trim, kern.cam.nda.0.unmapped_io, kern.cam.nda.0.trim_{ticks,goal}

    В любом случае, нужен PR.

    Eugene
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Alex Korchmar@2:5020/400 to Eugene Grosbein on Sun Sep 3 15:24:46 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>

    Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

    https://www.truenas.com/community/threads/unmap-failed.85345/
    https://forums.freebsd.org/threads/zfs-unmap-and-vmware-esxi-troubles.77648/
    https://forum.netgate.com/topic/167882/scsi-error-on-vm
    что сделали генитальные разработчики freebsd по этому поводу?
    Правильно - забили х-й.
    Hу не выяснять же ж на самом деле, что сломалось.
    Во-первых, первое и третье вообще не репорты в FreeBSD.
    ну а ничего что разработчики трунаса в целом-то те же самые люди?

    Во-вторых, UNMAP failed это ошибка, которую (виртуализированное) железо выдаёт драйверу в ответ на его команду SCSI UNMAP и сделать с этим драйвер
    там история интересна тем что оно сломалось с очередной версией
    вмвари и неплохо бы было разобраться, чего это вдруг.

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

    Максимум, что может сделать гостевая OS в таком случае, это попытаться найти workaround. В случае da0 для этого у нас есть подсистема CAM
    мне помогло вот такое:
    vfs.zfs.vol.unmap_enabled="0"
    vfs.zfs.trim.enabled="0"
    vfs.zfs.vdev.trim_on_init="0"

    что именно из перечисленного и что вообще значат эти заклинания - не в курсе. Hо с ними ушли и ошибки и периодическое мертвое взвисание сервера тоже.

    А ещё вместо эмуляции аппаратного контроллера LSI Logic
    нынче полезно отдавать виртуалке носитель в виде VirtIO block device
    боюсь это к итальянцам.

    В любом случае, нужен PR.
    для 12й версии это имеет хоть какой-то смысл? У меня, разумеется, 11 но баг видимо одинаков.

    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)
  • From Eugene Grosbein@2:5006/1 to Alex Korchmar on Sun Sep 3 22:14:00 2023
    03 сент. 2023, воскресенье, в 15:24 NOVT, Alex Korchmar написал(а):

    https://www.truenas.com/community/threads/unmap-failed.85345/
    https://forums.freebsd.org/threads/zfs-unmap-and-vmware-esxi-troubles.77648/
    https://forum.netgate.com/topic/167882/scsi-error-on-vm
    что сделали генитальные разработчики freebsd по этому поводу?
    Правильно - забили х-й.
    Hу не выяснять же ж на самом деле, что сломалось.
    Во-первых, первое и третье вообще не репорты в FreeBSD.
    ну а ничего что разработчики трунаса в целом-то те же самые люди?

    Знаю только одного из пересечения и он не работает в техподдержке
    первого уровня трунаса. Это не "в целом-то те же самые люди".

    Во-вторых, UNMAP failed это ошибка, которую (виртуализированное) железо
    выдаёт драйверу в ответ на его команду SCSI UNMAP и сделать с этим драйвер
    там история интересна тем что оно сломалось с очередной версией
    вмвари и неплохо бы было разобраться, чего это вдруг.

    Так и разбираться надо с vmware.

    особо ничего не может. Это тащем-то надо репортить разработчикам
    гипервизора
    их личный кабинет больше не мой личный кабинет, так что увы, но не мне.
    Максимум, что может сделать гостевая OS в таком случае, это попытаться
    найти workaround. В случае da0 для этого у нас есть подсистема CAM
    мне помогло вот такое:
    vfs.zfs.vol.unmap_enabled="0"
    vfs.zfs.trim.enabled="0"
    vfs.zfs.vdev.trim_on_init="0"
    что именно из перечисленного и что вообще значат эти заклинания - не в курсе.
    Hо с ними ушли и ошибки и периодическое мертвое взвисание сервера тоже.

    Тебе помогло vfs.zfs.trim.enabled="0", то есть ZFS вообще перестала посылать TRIM/UNMAP контроллеру и далее виртулизированному железу. Если бы это
    было настоящее железо с SSD, последствия были бы нехорошими,
    ну а так просто гостевая фря перестала сообщать гипервизору,
    которые блоки виртуального HDD она больше не использует.

    А ещё вместо эмуляции аппаратного контроллера LSI Logic
    нынче полезно отдавать виртуалке носитель в виде VirtIO block device
    боюсь это к итальянцам.
    В любом случае, нужен PR.
    для 12й версии это имеет хоть какой-то смысл? У меня, разумеется, 11 но баг
    видимо одинаков.

    Поддержка 12й версии заканчивается в конце этого года, смысла нет,
    тем более что косяк это в гипервизоре.

    Eugene
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Alex Korchmar@2:5020/400 to Eugene Grosbein on Tue Sep 5 02:04:55 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>

    Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

    там история интересна тем что оно сломалось с очередной версией
    вмвари и неплохо бы было разобраться, чего это вдруг.
    Так и разбираться надо с vmware.
    неочевидно. В вендепоганой ведь ничего не сломалось.
    Вполне возможно что вмварь так пытается намекнуть что в данной
    конфигурации trim не поддерживается и бесполезен, и система должна
    как-то иначе отреагировать.
    Интересно, вот это вот - к чему и не надо ли выключить нафиг?
    kernel: da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>

    А по факту имеем вот такое:
    kernel: (da0:mpt0:0:0:0): UNMAP failed, switching to WRITE SAME(16) with UNMAP BIO_DELETE
    kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 08 00
    kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
    kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
    kernel: (da0:mpt0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
    kernel: (da0:mpt0:0:0:0): Command byte 7 is invalid
    kernel: (da0:mpt0:0:0:0): Error 22, Unretryable error
    и дальше:
    kernel: (da0:mpt0:0:0:0): WRITE SAME(16). CDB: 93 08 00 00 00 00 01 ba 3f f0 00 00 00 20 00 00
    kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
    kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
    kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:80,85 (Vendor Specific ASC)
    kernel: (da0:mpt0:0:0:0): Info: 0
    kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
    kernel: (da0:mpt0:0:0:0): WRITE SAME(16). CDB: 93 08 00 00 00 00 01 b7 bc 60 00 00 00 08 00 00
    kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
    kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
    kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:80,85 (Vendor Specific ASC)
    - через некоторое время такой "работы" все виснет.


    Hу и разбираться, даже если есть шанс повлиять на вмварь, лучше
    кому-то проживающему подальше от территории страны-изгоя.


    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)
  • From Eugene Grosbein@2:5006/1 to Alex Korchmar on Tue Sep 5 10:08:54 2023
    05 сент. 2023, вторник, в 02:04 NOVT, Alex Korchmar написал(а):

    там история интересна тем что оно сломалось с очередной версией
    вмвари и неплохо бы было разобраться, чего это вдруг.
    Так и разбираться надо с vmware.
    неочевидно. В вендепоганой ведь ничего не сломалось.
    Вполне возможно что вмварь так пытается намекнуть что в данной конфигурации trim не поддерживается и бесполезен, и система должна
    как-то иначе отреагировать.
    Интересно, вот это вот - к чему и не надо ли выключить нафиг?
    kernel: da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>

    Это как раз костыли для Vmware:

    /usr/src/sys/cam/scsi/scsi_da.c

    /*
    * VMware returns BUSY status when storage has transient
    * connectivity problems, so better wait.
    * Also VMware returns odd errors on misaligned UNMAPs.
    */
    {T_DIRECT, SIP_MEDIA_FIXED, "VMware*", "*", "*"},
    /*quirks*/ DA_Q_RETRY_BUSY | DA_Q_STRICT_UNMAP

    Возможно, наоборот, сюда надо ещё костылей напихать типа DA_Q_NO_UNMAP
    вместо DA_Q_STRICT_UNMAP. Покажи grep da0 /var/run/dmesg.boot
    от этой версии Vmware и кусок pciconf -lvvv касательно дискового
    контроллера.

    Eugene
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Eugene Grosbein@2:5006/1 to Alex Korchmar on Tue Sep 5 10:16:13 2023
    31 авг. 2023, четверг, в 09:03 NOVT, Alex Korchmar написал(а):

    https://www.truenas.com/community/threads/unmap-failed.85345/ https://forums.freebsd.org/threads/zfs-unmap-and-vmware-esxi-troubles.77648/
    https://forum.netgate.com/topic/167882/scsi-error-on-vm
    что сделали генитальные разработчики freebsd по этому поводу?
    Правильно - забили х-й.
    Hу не выяснять же ж на самом деле, что сломалось.

    Hеправда. Как раз Мотин и выяснил и добавил костыль, пять лет назад.

    https://cgit.freebsd.org/src/commit/sys/cam/scsi/scsi_da.c?id=6fffdbbd67657bb5374019dd34c8155b3406cad8

    Add new quirk DA_Q_STRICT_UNMAP for cases when target is too critical to misaligned UNMAP request, reporting errors instead of being suboptimal.
    Setting this quirk makes da periph to forcefully align all UNMAP requests
    to avoid those errors by the cost of some odd ranges not being UNMAP'ed.
    This makes UNMAP usable within VMware 6.x VMs, just now 100% efficient.

    MFC after: 2 weeks

    Это изменение вошло в 11.1, так что твоя проблема, наверное,
    это какой-то новый косяк в Vmware.

    Eugene
    --
    Кара за одно съеденное яблоко, все-таки, была несоизмеримо велика,
    приступ диареи послужил бы достаточным уроком.
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Eugene Grosbein@2:5006/1 to All on Tue Sep 5 10:23:33 2023
    05 сент. 2023, вторник, в 10:08 NOVT, Eugene Grosbein написал(а):

    там история интересна тем что оно сломалось с очередной версией
    вмвари и неплохо бы было разобраться, чего это вдруг.
    Так и разбираться надо с vmware.
    неочевидно. В вендепоганой ведь ничего не сломалось.
    Вполне возможно что вмварь так пытается намекнуть что в данной
    конфигурации trim не поддерживается и бесполезен, и система должна
    как-то иначе отреагировать.
    Интересно, вот это вот - к чему и не надо ли выключить нафиг?
    kernel: da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>
    Это как раз костыли для Vmware:
    /usr/src/sys/cam/scsi/scsi_da.c
    /*
    * VMware returns BUSY status when storage has transient
    * connectivity problems, so better wait.
    * Also VMware returns odd errors on misaligned UNMAPs.
    */
    {T_DIRECT, SIP_MEDIA_FIXED, "VMware*", "*", "*"},
    /*quirks*/ DA_Q_RETRY_BUSY | DA_Q_STRICT_UNMAP
    Возможно, наоборот, сюда надо ещё костылей напихать типа DA_Q_NO_UNMAP вместо DA_Q_STRICT_UNMAP. Покажи grep da0 /var/run/dmesg.boot
    от этой версии Vmware и кусок pciconf -lvvv касательно дискового контроллера.

    И кстати сказать, с 12.0 поддерживается kern.cam.da.X.quirks для loader.conf, то есть, можно менять квирки без патчей сорцов и пересборки ядра/драйвера da.

    Eugene
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Eugene Grosbein@2:5006/1 to Alex Korchmar on Tue Sep 5 10:28:30 2023
    31 авг. 2023, четверг, в 09:03 NOVT, Alex Korchmar написал(а):
    https://www.truenas.com/community/threads/unmap-failed.85345/
    https://forums.freebsd.org/threads/zfs-unmap-and-vmware-esxi-troubles.77648/
    https://forum.netgate.com/topic/167882/scsi-error-on-vm
    что сделали генитальные разработчики freebsd по этому поводу?
    Правильно - забили х-й.
    Hу не выяснять же ж на самом деле, что сломалось.

    Hеправда. Как раз Мотин и выяснил и добавил костыль, пять лет назад. https://cgit.freebsd.org/src/commit/sys/cam/scsi/scsi_da.c?id=6fffdbbd67657bb5374019dd34c8155b3406cad8
    Add new quirk DA_Q_STRICT_UNMAP for cases when target is too critical to misaligned UNMAP request, reporting errors instead of being suboptimal. Setting this quirk makes da periph to forcefully align all UNMAP requests to avoid those errors by the cost of some odd ranges not being UNMAP'ed. This makes UNMAP usable within VMware 6.x VMs, just now 100% efficient. MFC after: 2 weeks
    Это изменение вошло в 11.1, так что твоя проблема, наверное,
    это какой-то новый косяк в Vmware.

    Тебе, кстати, никто не мешает написать Мотину на mav@freebsd.org
    по-русски со теми твоими ссылками и своими эффектами и задать вопрос.
    Очень может быть, что он позже добавлял ещё костылей для Vwmware, просто
    у тебя версия фряхи слишком стара.

    Eugene
    --
    Поэты - страшные люди. У них все святое.
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Nil A@2:5015/46 to Alex Korchmar on Tue Sep 5 07:36:42 2023
    Hello, Alex!

    Tuesday September 05 2023 02:04, from Alex Korchmar -> Eugene Grosbein:

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

    Вмвари платная, почему бы не Виртуалбокс?

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5
    * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
  • From Alex Korchmar@2:5020/400 to Eugene Grosbein on Sat Sep 9 09:02:21 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>

    Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

    Add new quirk DA_Q_STRICT_UNMAP for cases when target is too critical to
    он же должен быть виден в логах? В логе его нет.
    Впрочем вряд ли поможет, поскольку после первой неудачи с UNMAP он перестает его использовать вовсе, и все становится еще хуже чем было до того.

    Это изменение вошло в 11.1, так что твоя проблема, наверное,
    судя по тем форумам, жалуются на vmfs6 и седьмую вмварь соответственно. Поддержка 6 появилась с vmvare 6.5

    И там что-то изменилось именно в области "reclaim space".
    В частности он просто не работал на дисках со снапшотами (на которые там отдельно и жалуются) если эти диски по размеру меньше 2T - у серверной
    вари снапшот это redo-log, и он не умел в unmap в старом формате.

    это какой-то новый косяк в Vmware.
    я бы не называл косяком вмвари проблему, проявляющуюся в маргинальной ОС.
    У линукса с виндой нет никаких косяков.

    Тем более что проблема не только в том что оно пытается выдавать неработающие команды, а в том что по результату виснет.


    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)
  • From Alex Korchmar@2:5020/400 to Nil A on Sat Sep 9 09:04:22 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>

    Nil A <Nil.A@f46.n5015.z2.fidonet.org> wrote:

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

    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)
  • From Alex Korchmar@2:5020/400 to Eugene Grosbein on Sat Sep 9 09:07:22 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>

    Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

    Возможно, наоборот, сюда надо ещё костылей напихать типа DA_Q_NO_UNMAP вместо DA_Q_STRICT_UNMAP. Покажи grep da0 /var/run/dmesg.boot
    ну я собственно уже показал то что имело смысл.

    da0 at mpt0 bus 0 scbus2 target 0 lun 0
    da0: <VMware Virtual disk 2.0> Fixed Direct Access SPC-4 SCSI device
    da0: 320.000MB/s transfers (160.000MHz DT, offset 127, 16bit)
    da0: Command Queueing enabled
    da0: 20480MB (41943040 512 byte sectors)
    da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>

    от этой версии Vmware и кусок pciconf -lvvv касательно дискового
    mpt0@pci0:0:16:0: class=0x010000 card=0x197615ad chip=0x00301000 rev=0x01 hdr=0x00
    vendor = 'Broadcom / LSI'
    device = '53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI'
    class = mass storage
    subclass = SCSI

    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)
  • From Eugene Grosbein@2:5006/1 to Alex Korchmar on Sat Sep 9 22:30:56 2023
    09 сент. 2023, суббота, в 09:02 NOVT, Alex Korchmar написал(а):

    Add new quirk DA_Q_STRICT_UNMAP for cases when target is too critical to
    он же должен быть виден в логах? В логе его нет.

    В твоём dmesg есть.

    Eugene
    --- slrn/1.0.3 (FreeBSD)
    * Origin: RDTC JSC (2:5006/1@fidonet)
  • From Alex Korchmar@2:5020/400 to Eugene Grosbein on Thu Sep 14 20:04:47 2023
    From: Alex Korchmar <noreply@linux.e-moe.ru>

    Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

    Add new quirk DA_Q_STRICT_UNMAP for cases when target is too critical to
    он же должен быть виден в логах? В логе его нет.
    В твоём dmesg есть.
    значит, не работаит. Hу ладно, тут из парижу пишутъ - УМВР. В смысле, тест
    в контролируемой среде не воспроизвелся. Возможно и правда ВР в тех версиях которых у меня уже не предвидится.

    Alex

    --- ifmail v.2.15dev5.4
    * Origin: Demos online service (2:5020/400)