dd's 'direct' flag will make the kernel do the IO immediately. Ray Higgs System z FCP Development Bld. 706, B24 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 [email protected]
Linux on 390 Port <[email protected]> wrote on 11/23/2010 06:18:27 AM: > Shane <[email protected]> > Sent by: Linux on 390 Port <[email protected]> > > 11/23/2010 06:18 AM > > Please respond to > Linux on 390 Port <[email protected]> > > To > > [email protected] > > cc > > Subject > > Re: Problems with DASD driver on SLES 11 SP1? > > "dd" is _the_ absolute worst option for backups. It is stupid, has no > concept of data integrity, and is stupid. > And the default conv options are appalling - and it's stunningly stupid. > > Great for image copies in failure/forensic situations, other than that > it's downright ... er, see above. > > [f]sync doesn't really help a lot in this situation either - from a > Linux perspective. Last I looked (on a non-z system), fsync doesn't > guarantee the (physical) I/O actually gets written then-and-there. > Linux has I/O schedulers in play, and then there is pdflush/BDI to > worry about waking up. Sometime, somewhere the I/O does get flushed. > Blktrace has been around for a while now - the (timimg) output makes > for interesting reading. > Then we have z/VM snoozing away in the corner ... Sebastian and his > cohorts can fill you in there. > > If it (ever) worked you were IMHO lucky. I'd be slipping some (long) > sleeps in your scripts. > > Shane ... > > On Tue, 23 Nov 2010 10:51:53 +0100 > Sebastian Ott wrote: > > > > 2. Problem: > > > > > > Because I lack the FLASHCOPY function I use for disk to disk copy > > > dd. > > > > > > dd bs=4096 if=/dev/dasdx of=/dev/dasdy > > > > > > In principle it works ok. But when I do a chccwdev -d 0.0.xxxx even > > > with an udevadm settle --timeout=20 afterwards, > > > the file system gets corrupted, when I attach it to another guest. > > > > > > I am really lost since all that was working well under SLES 10 SP2. > > > I would really like to know if someone had similar experience in > > > SLES 11 SP1. > > > > The data is not guaranteed to be written in this case. This is due to > > changes in the linux block layer (it was not guaranteed to be written > > in sles 10 either but worked by chance). > > You have 2 options here: > > * tell dd to sync its data (check the man page - i think the option is > > fsync) > > * manually run "sync" after dd returns > > ---------------------------------------------------------------------- > 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 more information on Linux on System z, visit > http://wiki.linuxvm.org/ ---------------------------------------------------------------------- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
