Rob, I'm sorry if I wasn't clear enough in my example :-) The user space doesn't typically care about the TOD - agreed. The TOD is the TOD and the wall-clock time observed by user space may correlate back to the TOD or may observe some +/- offset, e.g. caused by NTP.
However, the disk device driver uses the TOD to time stamp its I/O. Of cause, the roll back isn't done on TOD values, but the *data* that is asynchronously replicated by XRC is indeed sorted by TOD value. If there are 2 OS instances, that have a requirement for data consistency managing their work units we also need TOD consistency because of the way XRC works. Applications may have nicely flushed their buffers or written data with O_DIRECT in the first place, but while the data from one tier (system) is replicated already, the data from the other tier (system) may still be queued for replication if the TODs are out of sync - specifically if we don't talk about msecs, but seconds or even worse minutes ... this may have many interesting effects on transactional rollback when 2-phase commits are broken after the fact due to an outage during replication. The transaction log from tier 1 assumes a 2-phase commit being finished for a unit of work and the log on tier 2 doesn't even show the transaction at all or some intermediary state only, and you may have further tiers that have already consumed the data regardless ... Time consistency in asynchronous data replication scenarios avoids much head aches you may face without! Best regards, Ingo -- Ingo Adlung, STSM, System z Linux and Virtualization Architecture mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263 Linux on 390 Port <[email protected]> wrote on 11.10.2006 20:41:46: > On 10/11/06, Ingo Adlung <[EMAIL PROTECTED]> wrote: > > > We are working to provide ETR support asap, but currently this > > anticipated support is limited to LPAR only, as z/VM doesn't provide > > the required guest support, yet. STP will follow. > > No doubt the lack of my imagination, but I think it would be > interesting to know which applications would take advantage of such > new function. I was not aware that people would make roll-back based > on TOD clock. All I have seen is where units of work are separated by > in-band markers and roll-back or commit being locked on those. > > The "consistency groups" is when two different parallel sysplex > configurations would both have the need to run on slightly different > time, and both need a Linux virtual machine on the same z/VM image to > run in synch with them? If it were only one, you could have z/VM run > along with the same clock and you would be fine. If so, that might not > be the first problem many of us run into, I would think. > > Rob > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
