Can somebody help me understand the practical aspects of this statement
from dmsetup(8) ?
suspend
device_name
Suspends a device. Any I/O that has already been mapped
by the
device but has not yet completed will be flushed. Any
further
I/O to that device will be postponed for as long as the
device
is suspended.
Specifically, I am researching possible approaches to solving the
problem of guaranteeing good DR backups and reliable clones of running
Linux users in combination with the CP FLASHCOPY facility of our DS8100.
The new AF_IUCV support will probably prove necessary in the effort, as
well as the asynchronous FLASHCOPY we're promised in z/VM 5.3. The
statement to the effect that "I/Os which have been mapped but not
completed will be flushed" is of some concern, but I am unsure of the
potential danger I would be exposing myself to, in any real terms.
Should it be a small concern? A large concern? My intial experimentation
seems to suggest it works in practice (given my small sample size), but
what are the theoretical dangers?
I get a better feeling from the 'freeze' capabilities of xfs, but as
deploying it in preference to something which uses the 'suspend'
capabilities of the device_mapper involves getting our distrubted
systems people to buy off on adopting xfs as the standard filesystem for
linux on zSeries, I would like to exhaust the possibilities of 'dmsetup
suspend', first.
This would be on SLES10; I am aware of the kernel panics people are
reporting with RHEL5 on intel systems and am assuming, for now, that it
is a non issue in our SuSE/zSeries environment (given I've been playing
with it and haven't seen a kernel panic myself).
ok
r.
----------------------------------------------------------------------
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
