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

Alex Korchmar написал(а) к All в Aug 23 09:03:52 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>


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

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

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

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Sep 23 10:10:37 по местному времени:

31 авг. 2023, четверг, в 09:03 NOVT, Alex Korchmar написал(а):

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

Во-первых, первое и третье вообще не репорты в 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 TНROUGН 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.enablebiospeedup, kern.cam.nda.maxtrim,
kern.cam.nda.0.unmappedio, kern.cam.nda.0.trim{ticks,goal}

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

Eugene
--- slrn/1.0.3 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Sep 23 02:04:55 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

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

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

А по факту имеем вот такое:
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)
- через некоторое время такой "работы" все виснет.


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


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Sep 23 10:08:54 по местному времени:

05 сент. 2023, вторник, в 02:04 NOVT, Alex Korchmar написал(а):

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

Это как раз костыли для 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.
*/
{TDIRECT, SIP_MEDIAFIXED, "VMware", "*", ""},
/quirks/ DAQ_RETRY_BUSY | DA_Q_STRICTUNMAP

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

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Sep 23 10:16:13 по местному времени:

31 авг. 2023, четверг, в 09:03 NOVT, Alex Korchmar написал(а):

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

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

https://cgit.freebsd.org/src/commit/...c8155b3406cad8

Add new quirk DAQ_STRICTUNMAP 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)

Eugene Grosbein написал(а) к All в Sep 23 10:23:33 по местному времени:

05 сент. 2023, вторник, в 10:08 NOVT, Eugene Grosbein написал(а):

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

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

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Sep 23 10:28:30 по местному времени:

EG> 31 авг. 2023, четверг, в 09:03 NOVT, Alex Korchmar написал(а):
AK>> https://www.truenas.com/community/th...-failed.85345/
AK>> https://forums.freebsd.org/threads/z...roubles.77648/
AK>> https://forum.netgate.com/topic/167882/scsi-error-on-vm
AK>> что сделали генитальные разработчики freebsd по этому поводу?
AK>> Правильно - забили х-й.
AK>> Ну не выяснять же ж на самом деле, что сломалось.

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

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

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.3 (FreeBSD)

Nil A написал(а) к Alex Korchmar в Sep 23 07:36:42 по местному времени:

Нello, Alex!

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

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

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

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Alex Korchmar написал(а) к Eugene Grosbein в Sep 23 09:02:21 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

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

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

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

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

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

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


> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Nil A в Sep 23 09:04:22 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

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

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

> Alex

--- ifmail v.2.15dev5.4