Hello Mark,

I'll have to look into the flashcopy process but have not taken the time for it 
just yet.

I guess one thing that would be wrong then is that I copy from the live system. 
So the source nlzlx920 is being copied from within the nlzlx920. But would that 
introduce IO errors on the target disks? If anything I'd expect to see errors 
during boot of the target guest. Either in a filesystemcheck or dmesg 
afterwards. Much like when you DDR a live VM and get a warmstartdata error when 
the target is IPLled. Perhaps a rethink of the process is in order. I guess a 
resque system would be an option. I do like to have a resque machine so I could 
also use that machine to do the cloning.

As for other questions, I also assume I have the rights. No errors on that 
part. Same amount of cylinders. I have not yet ran the fsck on the source nor 
did I test it in a failsafe IPL of a new target. I dd with "dd bs=4096 if=$sDev 
of=$tDev" no other options. Haven't ran dd during the process by hand, other 
than a manual test to clone the first machine and to test the steps in the 
script. No erep or errors within the operator log. There is no error from the 
VM part. It's only within the linux.

Regards, Berry.

-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry
Sent: donderdag 21 augustus 2008 12:22
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Root filesystem error switches to ReadOnly

van Sleeuwen, Berry wrote:
> Hello Mark,
> 
> I meant fast in a way that the / is copied and then changes the hostname and 
> IP address. No other fancy things, just a default environment for our support 
> staff to play around with.
> 
> The cloning process is loosly based on the cloning scripts from redp4322. The 
> dasd is copied using DASDFMT and dd. Both source (installation machine) and 
> targets are identical, other than the obvious different location of the 
> minidisk extents. The / is a 3338 cylinder minidisk so there it even uses the 
> same minidisk extents but on different DASD volumes. There is one thing I now 
> see, I first regarded as an error due to new disks, but it is still present 
> even when the disks were in use for the guest before. When the copy is done 
> there are some IO errors.
> 

FLASHCOPY is still faster ;-)

> 08/08/19 13:41:20 NLZLX920 VMLXES21:  end_request: I/O error, dev dasdd, 
> sector 361776Ÿprintk: 630 messages suppressed.ŸBuffer I/O
> 08/08/19 13:41:20 NLZLX920 VMLXES21    error on device dasdd, logical block 
> 45222Ÿlost page write due to I/O error on dasddŸBuffer
> 08/08/19 13:41:20 NLZLX920 VMLXES21    I/O error on device dasdd, logical bl
> 
> The disk is linked, then DASDFMT and dd. It looks like the IO errors appear 
> within the dd part of the copy process. But how to fix that? Should the guest 
> have some mdisk option to avoid errors?
> 
> Thanks, Berry.
> 
If doing a dd from linux and the minidisks are identical in size, then one must 
assume that you have the rights to write to all cylinders.

If you issue a vmcp q v da - are source and target the same number of cylinders?

I also assume that the source and target are not mounted to Linux while the dd 
is running?

Have you done an fsck on the source volume to ensure it is good?
Are you specifying any dd options?
Can you do a foreground dd (with -v) and reproduce the error?
Is z/VM logging anything - EREP?

mark

----------------------------------------------------------------------
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
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this transmission 
is virus-free and will not be

liable for any damages resulting from 
any virus transmitted.

 

On all offers and agreements under 
which Atos Origin supplies goods and/or

services of whatever nature, the Terms 
of Delivery from Atos Origin

exclusively apply. 

The Terms of Delivery shall be promptly 
submitted to you on your request.

 

Atos Origin Nederland B.V. / Utrecht

KvK Utrecht 30132762

Reply via email to