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. 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
