Re: Kernel Level Generic Target Mode control path

[Vladislav Bolkhovitin <vst@vlnb.net>]

Bart Van Assche wrote:
> On Fri, Aug 29, 2008 at 6:28 PM, Vladislav Bolkhovitin <vst@vlnb.net> 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.
>