LIO FC Target - SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 819

[snow]

Hallo Leute,

Als SAN Storage betreibe ich einen Fedora 21 Server mit Kernel 3.17.4-301.fc21.x86_64.
Auf diesem System werden die Luns via targetcli an einen ESXi Server 6.0 Server freigegeben.
Beide Systeme sind via FC (Qlogic 2460 in beiden Systemen) direkt verbunden.

Soweit funktioniert auch alles einwandfrei.
Als Gastsysteme auf dem ESXi laufen z.b. Windows 7 und CentOS 7, sowie Fedora 21 ohne Probleme.

Wenn ich jetzt versuche auf dem ESXi ein neues Gastsystem mit Fedora 22 zu installieren, bekomme ich folgende Fehler auf dem Target Server:

Jul 31 13:21:54 san1 kernel: [ 87.140969] sbc_parse_cdb: 1243 callbacks suppressed
Jul 31 13:21:54 san1 kernel: [ 87.140977] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: sbc_parse_cdb: 1243 callbacks suppressed
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.145879] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.149636] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.154563] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.159447] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.162644] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.167550] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.170546] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.173653] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: [ 87.178587] SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192
Jul 31 13:21:54 san1 kernel: SCSI OP 2ah with too big sectors 8528 exceeds fabric_max_sectors: 8192

Gibt's da irgendeine Lösung?
Ich blicke da in den Mailinglisten leider nicht durch.

Ich habe zum testen auf dem Target Server bereits Fedora 22 mit Kernel 4.0.8.x versucht, leider hängt sich dann irgendwann die ganze Büchse auf mit:

Jul 27 08:02:28 san1 kernel: ABORT_TASK: Found referenced qla2xxx task_tag: 1161204
Jul 27 08:02:28 san1 kernel: ------------[ cut here ]------------
Jul 27 08:02:28 san1 kernel: kernel BUG at drivers/scsi/qla2xxx/qla_target.c:2806!
Jul 27 08:02:28 san1 kernel: invalid opcode: 0000 [#1] SMP
Jul 27 08:02:28 san1 kernel: Modules linked in: tcm_qla2xxx target_core_user uio target_core_pscsi target_core_file target_core_iblock iscsi_target_mod target_core_mod it87 hwmon_vid joydev k10temp hid_logitech_hidpp kvm hid_logitech_dj edac_core edac_mce_amd tpm_infineon tpm_tis sp5100_tco i2c_piix4 tpm wmi shpchp acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c qla2xxx serio_raw scsi_transport_fc r8169 megaraid_sas mii
Jul 27 08:02:28 san1 kernel: CPU: 0 PID: 83 Comm: kworker/u16:6 Not tainted 4.0.8-300.fc22.x86_64 #1
Jul 27 08:02:28 san1 kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3, BIOS F6 05/30/2012
Jul 27 08:02:28 san1 kernel: Workqueue: tmr-iblock target_tmr_work [target_core_mod]
Jul 27 08:02:28 san1 kernel: task: ffff8800da286360 ti: ffff8800da2dc000 task.ti: ffff8800da2dc000
Jul 27 08:02:28 san1 kernel: RIP: 0010:[<ffffffffa00c6270>] [<ffffffffa00c6270>] qlt_free_cmd+0x140/0x170 [qla2xxx]
Jul 27 08:02:28 san1 kernel: RSP: 0018:ffff8800da2dfc48 EFLAGS: 00010002
Jul 27 08:02:28 san1 kernel: RAX: 0000000000000000 RBX: ffff88020d973a80 RCX: ffffffffa00ed498
Jul 27 08:02:28 san1 kernel: RDX: 000000000000e074 RSI: ffff880213823798 RDI: 0000000000004000
Jul 27 08:02:28 san1 kernel: RBP: ffff8800da2dfc78 R08: ffffffffa00db628 R09: ffff88020d973a80
Jul 27 08:02:28 san1 kernel: R10: ffff880036e5f480 R11: 000000000000047a R12: ffff88021267f680
Jul 27 08:02:28 san1 kernel: R13: ffff88020d973a80 R14: 0000000000000000 R15: 0000000000000000
Jul 27 08:02:28 san1 kernel: FS: 00007f9dcc030800(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
Jul 27 08:02:28 san1 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jul 27 08:02:28 san1 kernel: CR2: 00007f5872e554d8 CR3: 00000000db3ac000 CR4: 00000000000007f0
Jul 27 08:02:28 san1 kernel: Stack:
Jul 27 08:02:28 san1 kernel: ffff880000000180 00010000ffffffff ffff8800da2dfcd8 ffff88020d973b40
Jul 27 08:02:28 san1 kernel: ffff880214fdfc80 ffff88020d973a80 ffff8800da2dfc88 ffffffffa0485d84
Jul 27 08:02:28 san1 kernel: ffff8800da2dfcb8 ffffffffa03c2496 0000000000000001 ffff880214fdfcf0
Jul 27 08:02:28 san1 kernel: Call Trace:
Jul 27 08:02:28 san1 kernel: [<ffffffffa0485d84>] tcm_qla2xxx_release_cmd+0x14/0x30 [tcm_qla2xxx]
Jul 27 08:02:28 san1 kernel: [<ffffffffa03c2496>] target_release_cmd_kref+0x56/0x90 [target_core_mod]
Jul 27 08:02:28 san1 kernel: [<ffffffffa03c3468>] target_put_sess_cmd+0xc8/0xe0 [target_core_mod]
Jul 27 08:02:28 san1 kernel: [<ffffffffa03c3738>] transport_release_cmd+0x48/0x70 [target_core_mod]
Jul 27 08:02:28 san1 kernel: [<ffffffffa03c4cac>] transport_cmd_finish_abort+0xdc/0x2e0 [target_core_mod]
Jul 27 08:02:28 san1 kernel: [<ffffffffa03bfb5d>] core_tmr_abort_task+0x15d/0x200 [target_core_mod]
Jul 27 08:02:28 san1 kernel: [<ffffffffa03c334f>] target_tmr_work+0xbf/0xd0 [target_core_mod]
Jul 27 08:02:28 san1 kernel: [<ffffffff810b5a1b>] process_one_work+0x1bb/0x410
Jul 27 08:02:28 san1 kernel: [<ffffffff810b5cc3>] worker_thread+0x53/0x470
Jul 27 08:02:28 san1 kernel: [<ffffffff810b5c70>] ? process_one_work+0x410/0x410
Jul 27 08:02:28 san1 kernel: [<ffffffff810bb728>] kthread+0xd8/0xf0
Jul 27 08:02:28 san1 kernel: [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180
Jul 27 08:02:28 san1 kernel: [<ffffffff81789f58>] ret_from_fork+0x58/0x90
Jul 27 08:02:28 san1 kernel: [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180
Jul 27 08:02:28 san1 kernel: Code: e9 54 ff ff ff 66 0f 1f 44 00 00 be 01 0b 00 00 48 c7 c7 e8 73 0e a0 e8 cf 65 fd e0 48 83 c4 18 5b 41 5c 41 5d 5d c3 0f 1f 40 00 <0f> 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 48 8b bb c8 02
Jul 27 08:02:28 san1 kernel: RIP [<ffffffffa00c6270>] qlt_free_cmd+0x140/0x170 [qla2xxx]
Jul 27 08:02:28 san1 kernel: RSP <ffff8800da2dfc48>
Jul 27 08:02:28 san1 kernel: ---[ end trace c781d4c0c585903a ]---

Die Kernel Version 4.1.3 bringt leider auch nix, das System läuft zwar etwas länger stabil, aber der gleiche Fehler kommt auch hier mal früher, mal später.

Zumindest mit Fedora 21 und Kernel 3.17.4-301.fc21.x86_64 gibt's dieses Problem nicht.
Jedoch brauche ich hier eine Lösung bzgl. "exceeds fabric_max_sectors".

Vielleicht kann mir da jemand einen Tipp geben.

Danke,
Philipp

[snow]

Wenn es noch jemand interessiert, die Aussichten auf ein Stable FC Target in LIO sind wohl eher bescheiden.
Die Lösung ist SCST. Funktioniert bestens.

Hab jetzt ESOS im Einsatz, kann ich nur empfehlen:
http://www.esos-project.com/