Bart Van Assche wrote:
On Fri, Aug 29, 2008 at 6:28 PM, Vladislav Bolkhovitin <vst@xxxxxxxx> wrote:
It has a big problem with atomicity of changes. Configuration of each iSCSI
target should be atomic and on the target driver's start configuration of
*all* targets as a whole should be atomic as well. How are you going to
solve this issue?
One way to solve this (I'm not saying it's the best way to solve this)
is to implement a transaction interface through configfs. A configfs
interface for transactions could e.g. be implemented as follows:
1. Provide one integer variable representing the sequence number of
the ongoing transaction. This variable is incremented before its value
is returned to userspace.
2. Provide as many variables as needed to allow entry of all the data
involved in the transaction.
3. Provide one variable for requesting a commit. A commit is requested
by writing a number to this variable. If and only if the value written
equals the current value of counter (1), a commit is performed.
Whether or not this action triggered a commit must be reported to
userspace, e.g. through errno.
User space processes must use this interface as follows:
(a) Read counter (1).
(b) Write all relevant data to (2).
(c) Write the value read in step (a) to variable (3).
(d) If step (c) reported that the transaction failed, go back to step (a).
This is an optimistic locking scheme that can be used by several
processes simultaneously and that survives processes that are killed
while performing a transaction.
Unfortunately, this seems to be a lot more complicated, than I would
want to have...
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
