|
About
TODO
Blog
RSS
Old blog
Projects
Gallery
Notes
Sat, 14 Jul 2007
More iSCSI wierdness and DST notes.
static void __iscsi_get_ctask(struct iscsi_cmd_task *ctask)
{
atomic_inc(&ctask->refcount);
}
static void iscsi_get_ctask(struct iscsi_cmd_task *ctask)
{
spin_lock_bh(&ctask->conn->session->lock);
__iscsi_get_ctask(ctask);
spin_unlock_bh(&ctask->conn->session->lock);
}
static void __iscsi_put_ctask(struct iscsi_cmd_task *ctask)
{
if (atomic_dec_and_test(&ctask->refcount))
iscsi_complete_command(ctask);
}
static void iscsi_put_ctask(struct iscsi_cmd_task *ctask)
{
spin_lock_bh(&ctask->conn->session->lock);
__iscsi_put_ctask(ctask);
spin_unlock_bh(&ctask->conn->session->lock);
}
I tried to avoid locks and alocations as much as possible in distributed storage,
but there are at least two locks in DST: one is used to put ready socket into queue
to be processed by dedicated thread in process context and another one to protect
queue of request for each given socket. There is also one possible additional allocation
in the IO request processing path - if it is impossible to complete request when it arrived
(it happens in process context on behalf of generic_make_request()) new request
is allocated from memory pool, which holds given block IO request and additional fields to
form processing state machine, to hold sending/receiving offsets and other fields,
then new request is queued to the tail of the request queue for given state, which holds
a socket. Actually there is always only one consumer (processing thread) and one producer
(a node which holds state which contains socket), so it would be possible to remove additional
locking, but producer is only one since block layer does not allow to run several
generic_make_request() processing functions simultaneously, which can be changed in future
(or not), so I will leave it as is for now.Actually looking at DST it becomes very similar to device mapper on top of network block device. Yes, network block device has some problems, but there is whole system in device mapper which allows to use existing redundancy algorithms (like different RAID arrays), so it looks like I just reinvent the wheel with my project (you can not even imagine how frequently I was told about the same with kevent and epoll), so I will implement a simple device mapper target too. Although it will be a bit limited, but it is noticebly simpler that existing system. It does not mean I will drop what I created, there will be just two operation modes. /devel/dst :: Link / Comments (0) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||