Re: plans for user-backed device support
by Andy Grover
On 02/04/2015 12:21 PM, Alex Elsayed wrote:
>> Maybe we step back and define a DBus interface
>
> I'd be quite happy with that - I considered suggesting it, in fact, but
> wasn't sure of the prevailing opinion re: dbus around here.
>
> What would you do re: discovery, though?
>
> (Explaining some DBus things, which readers may already be aware of)
>
> In DBus, there's a two-level hierarchy of busnames holding objects.
> Busnames are either the inherent, connection-level one of the :\d+.\d+ form,
> or the human-readable well-known name form (reverse DNS). Objects, then,
> implement interfaces.
>
> However, well-known names can only have a single owner - so discovering
> which busnames have objects which implement an interface is non-trivial.
>
> The approach taken by KDE is to suffix the well-known name with the PID
> (org.kde.StatusNotifierItem-2055 or whatever), call ListNames, and filter in
> the client. This has the drawback of making DBus activation impossible.
>
> Another approach is for every implementor to try to claim the well-known
> name, and on failure contact the existing owner to republish their objects
> (possibly under a namespaced object path). This has the drawback of
> complicating the implementation somewhat, as well as making bus activation
> only able to activate a single 'default' implementation.
>
> A third approach would be to explicitly define a multiplexor, which backends
> ask to republish their objects. This simplifies implementations, and it
> could also provide its own API that requests a backend by name, and ensures
> that backend's object is available. This could be driven by something as
> simple as a key-value mapping from backend name to a well-known DBus name
> specific to that backend, which the multiplexor calls to trigger service
> activation.
>
> Thoughts?
It really seems to come down to: will multiple independent user-handler
daemons be needed? Because I'm trying really hard to make tcmu-runner
good enough so that the answer is no :-)
tcmu-runner supports multiple handler modules, so it's extensible. It is
permissively licensed so no issues with non-FOSS handlers needing their
own daemon. It also could be replaced entirely (either with a modified
version of itself or from scratch) and still not give up the
single-busname, service activation approach.
So that would be my current preference. (The fact that the kernel API
doesn't preclude multiple handler daemons does not mean we need to
*support* those right away, or ever.)
If there are likely use cases that tcmu-runner is unsuitable for solving
by itself then that would change things of course, and let's please talk
about them!
-- Andy
8 years, 8 months
Fwd: max_unmap_lba_count too large by default
by Andy Grover
-------- Forwarded Message --------
Subject: max_unmap_lba_count too large by default
Date: Thu, 27 Aug 2015 16:47:48 +0200
From: Tomasz Charoński <t.charonski(a)beyond.pl>
To: targetcli-fb-devel-bounces(a)lists.fedorahosted.org
Hello,
the attribute max_unmap_lba_count of iblock backstore (maybe in other
backstores too) is definitely too large by default: 4194304. It allows
SCSI to accept so big SCSI unmap commands, that target eventually ends
with timeout, because backend storage processes it too long:
Aug 17 09:51:01 debian8 kernel: [330755.353723] INFO: task
kworker/10:1:5423 blocked for more than 120 seconds.
Aug 17 09:51:01 debian8 kernel: [330755.353773] Tainted:
P O 4.0.4 #1
Aug 17 09:51:01 debian8 kernel: [330755.353807] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 17 09:51:01 debian8 kernel: [330755.353867] kworker/10:1 D
ffff88203f014440 0 5423 2 0x00000000
Aug 17 09:51:01 debian8 kernel: [330755.353884] Workqueue:
tcm_qla2xxx_free tcm_qla2xxx_handle_data_work [tcm_qla2xxx]
Aug 17 09:51:01 debian8 kernel: [330755.353888] ffff882021f722d0
ffff88149219fbf8 ffff881038c7a190 0000000000000001
Aug 17 09:51:01 debian8 kernel: [330755.353893] ffff88149219ffd8
ffff88203f014440 7fffffffffffffff ffff882021f722d0
Aug 17 09:51:01 debian8 kernel: [330755.353896] ffff88149219fcd0
0000000000000000 ffffffff815640cf 0000000000000000
Aug 17 09:51:01 debian8 kernel: [330755.353901] Call Trace:
Aug 17 09:51:01 debian8 kernel: [330755.353918] [<ffffffff815640cf>] ?
schedule+0x2f/0x80
Aug 17 09:51:01 debian8 kernel: [330755.353924] [<ffffffff8156744a>] ?
schedule_timeout+0x21a/0x290
Aug 17 09:51:01 debian8 kernel: [330755.353936] [<ffffffff812a5eaf>] ?
generic_make_request_checks+0x1df/0x3d0
Aug 17 09:51:01 debian8 kernel: [330755.353947] [<ffffffff8101cf75>] ?
read_tsc+0x5/0x10
Aug 17 09:51:01 debian8 kernel: [330755.353952] [<ffffffff815636ea>] ?
io_schedule_timeout+0xba/0x150
Aug 17 09:51:01 debian8 kernel: [330755.353957] [<ffffffff81564ab5>] ?
wait_for_completion_io+0xb5/0x180
Aug 17 09:51:01 debian8 kernel: [330755.353967] [<ffffffff81098fa0>] ?
wake_up_state+0x20/0x20
Aug 17 09:51:01 debian8 kernel: [330755.353973] [<ffffffff812b0fab>] ?
blkdev_issue_discard+0x20b/0x270
Aug 17 09:51:01 debian8 kernel: [330755.353983] [<ffffffffa0543270>] ?
iblock_execute_unmap+0x30/0x30 [target_core_iblock]
Aug 17 09:51:01 debian8 kernel: [330755.353988] [<ffffffffa054328f>] ?
iblock_do_unmap+0x1f/0x50 [target_core_iblock]
Aug 17 09:51:01 debian8 kernel: [330755.354003] [<ffffffffa07af65c>] ?
sbc_execute_unmap+0x12c/0x270 [target_core_mod]
Aug 17 09:51:01 debian8 kernel: [330755.354010] [<ffffffff810125eb>] ?
__switch_to+0x14b/0x5d0
Aug 17 09:51:01 debian8 kernel: [330755.354020] [<ffffffffa07ac4aa>] ?
__target_execute_cmd+0x1a/0xa0 [target_core_mod]
Aug 17 09:51:01 debian8 kernel: [330755.354026] [<ffffffff81086a02>] ?
process_one_work+0x152/0x440
Aug 17 09:51:01 debian8 kernel: [330755.354031] [<ffffffff8108757b>] ?
worker_thread+0x6b/0x560
Aug 17 09:51:01 debian8 kernel: [330755.354035] [<ffffffff81087510>] ?
rescuer_thread+0x3b0/0x3b0
Aug 17 09:51:01 debian8 kernel: [330755.354041] [<ffffffff8108c533>] ?
kthread+0xd3/0xf0
Aug 17 09:51:01 debian8 kernel: [330755.354045] [<ffffffff8108c460>] ?
kthread_create_on_node+0x180/0x180
Aug 17 09:51:01 debian8 kernel: [330755.354050] [<ffffffff81568798>] ?
ret_from_fork+0x58/0x90
Aug 17 09:51:01 debian8 kernel: [330755.354054] [<ffffffff8108c460>] ?
kthread_create_on_node+0x180/0x180
To prevent such timeouts I suggest to set max_unmap_lba_count by default
to 65535.
Best regards,
--
Tomasz Charoński
Storage Administrator
Ul. M. Palacza 113
60-273 Poznań
tel.: +48 61 859 70 07
fax: +48 61 623 25 79
www.beyond.pl <http://www.beyond.pl>
biuro(a)beyond.pl <mailto:biuro@beyond.pl>
NIP: 782-23-24-152
KRS: 0000237620
Sąd Rejonowy Poznań-Nowe Miasto i Wilda w Poznaniu
VIII Wydział Gospodarczy Krajowego Rejestru Sądowego
Kapitał Zakładowy: 2 539 700,00 PLN
UWAGA: Ta wiadomość oraz wszelkie załączniki są przeznaczone wyłącznie
dla adresata korespondencji e-mail. Jeśli otrzymałeś ten e-mail przez
pomyłkę, prosimy niezwłocznie powiadom nadawcę i usuń przesyłkę ze
swojego systemu wraz ze wszystkimi załącznikami. Kopiowanie,
dystrybucja, ujawnianie i inne wykorzystanie przesyłki e-mail, bez zgody
nadawcy, jest zakazane.
8 years, 9 months