You are not logged in.

Announcement

[2014.03.27] DeployStudio last nightly build (release note).
[2013.08.29] DeployStudio last stable build (release note).
[2013.02.23] DeployStudio last universal stable build (release note).

#1 2009-11-05 17:13:46

CherylT
Member
Registered: 2009-10-02

Multicast restore failing with XDBG failed requests

Hello. I am new to DS and have been working on getting to know the software and testing it for multicast imaging and deployment. I have successfully created, deployed and restored a unicast image of nothing more than a 10.6.1 OS.
I have also successfully created, deployed and restored a unicast image of my current 10.5.8 lab production image.

My setup is:

? DS rc15
? Intel Xserve w/8GB RAM running DS Admin/Runtime and Repository
? A dedicated GB switch to a vlan subnet with 37 Alum iMacs.
? I followed instructions in DS manual on how to determine Data Rate Stream and Disk Speed. (Viewing Server Admin>AFP>Graphs>Throughput after a unicast restore)

I have successfully created, deployed and restored a multicast image of nothing more than a 10.6.1 OS.

I have not been successful in restoring a multicast image of my 10.5.8 production image. This image was created with a DS workflow.

In initial testing I was being hit with XDGB request failures throughout the restore process.
At that time my Data Rate and Disk Speeds were set at:
en0: 25 MB/s
disk0: 35 MB/s

After searching through the forums I found this tip [url]http://www.deploystudio.com/Forums/viewtopic.php?id=1299[/url] (see: rule of thumb)

I then changed by Data Rate settings to:
en0: 25 MB/s
disk0: 75 MB/s

This change eliminated all of the XDGB request failures except for some that show up at the point of 98 progress.

I then dropped my Data Rate settings to:
en0:12 MB/s
disk0: 35 MB/s

Multicast restore still fails at the point of 98 progress.

Here is a log of one of the failures.
2009-11-04 14:33:02.816 Runtime[173:5d27] Multicast restoration from url 'asr://128.226.62.3:7801'.
2009-11-04 14:33:03.051 Runtime[173:5d27] Setting boot device to '/dev/disk0s2'.
2009-11-04 14:33:03.070 Runtime[173:5d27] /usr/sbin/diskutil unmount force /dev/disk0s2 2>&1
2009-11-04 14:33:03.212 Runtime[173:5d27] Volume Untitled on disk0s2 force-unmounted
2009-11-04 14:33:13.237 Runtime[173:5d27] /usr/sbin/asr restore --source asr://128.226.62.3:7801 --target /dev/disk0s2 --erase --puppetstrings --noprompt --noverify 2>&1
2009-11-04 14:33:13.436 Runtime[173:5d27] XSTA    start    137    multicast-client
2009-11-04 14:33:13.438 Runtime[173:5d27] XSTA    setup
2009-11-04 14:33:13.442 Runtime[173:5d27]     Validating target...done
2009-11-04 14:33:13.443 Runtime[173:5d27] XSTA    metadata
2009-11-04 14:33:13.990 Runtime[173:5d27]     Validating source...done
2009-11-04 14:33:19.570 Runtime[173:5d27]     Erasing target device /dev/disk0s2...done
2009-11-04 14:33:19.575 Runtime[173:5d27]     Retrieving scan information...done
2009-11-04 14:33:19.578 Runtime[173:5d27]     Validating sizes...done
2009-11-04 14:33:19.770 Runtime[173:5d27] XSTA    restore
2009-11-04 14:33:19.771 Runtime[173:5d27] PSTT    0    100    start restore
2009-11-04 14:34:38.923 Runtime[173:5d27] Progress: 2
2009-11-04 14:38:34.338 Runtime[173:5d27] Progress: 8
2009-11-04 14:42:29.934 Runtime[173:5d27] Progress: 14
2009-11-04 14:46:25.465 Runtime[173:5d27] Progress: 20
2009-11-04 14:50:21.008 Runtime[173:5d27] Progress: 26
2009-11-04 14:54:16.813 Runtime[173:5d27] Progress: 32
2009-11-04 14:58:12.669 Runtime[173:5d27] Progress: 38
2009-11-04 15:02:08.394 Runtime[173:5d27] Progress: 44
2009-11-04 15:06:00.735 Runtime[173:5d27] Progress: 50
2009-11-04 15:09:55.480 Runtime[173:5d27] Progress: 56
2009-11-04 15:13:51.801 Runtime[173:5d27] Progress: 62
2009-11-04 15:17:47.557 Runtime[173:5d27] Progress: 68
2009-11-04 15:21:43.665 Runtime[173:5d27] Progress: 74
2009-11-04 15:25:33.647 Runtime[173:5d27] Progress: 80
2009-11-04 15:29:12.150 Runtime[173:5d27] Progress: 86
2009-11-04 15:32:48.565 Runtime[173:5d27] Progress: 92
2009-11-04 15:36:11.953 Runtime[173:5d27] Progress: 98
2009-11-04 15:37:07.579 Runtime[173:5d27] XDBG    failed request for 16384 bytes at position 3602432
2009-11-04 15:37:07.580 Runtime[173:5d27] XDBG    failed request for 8192 bytes at position 3864576
2009-11-04 15:37:07.580 Runtime[173:5d27] XDBG    failed request for 8192 bytes at position 4126720
2009-11-04 15:37:07.581 Runtime[173:5d27] XDBG    failed request for 8192 bytes at position 4388864
2009-11-04 15:37:07.581 Runtime[173:5d27] XDBG    failed request for 8192 bytes at position 4651008
2009-11-04 15:37:07.582 Runtime[173:5d27] XDBG    failed request for 8192 bytes at position 4913152
2009-11-04 15:37:07.582 Runtime[173:5d27] XDBG    failed request for 8192 bytes at position 5175296
2009-11-04 15:37:15.271 Runtime[173:5d27] PSTP    100    100    stop restore
2009-11-04 15:37:15.272 Runtime[173:5d27] XSTA    Retry <1m
2009-11-04 15:37:15.273 Runtime[173:5d27] PSTT    0    100    start restore retry
2009-11-04 15:37:15.343 Runtime[173:5d27] Command failure: XSTA    fail: packet loss
2009-11-04 15:37:23.893 Runtime[173:5d27] Restoration failed
2009-11-04 15:37:24.269 Runtime[173:5d27] -> Restore action completed.
2009-11-04 15:37:24.269 Runtime[173:5d27] Restoration failure (elapsed time: 64.36 minutes)
2009-11-04 15:37:55.537 Runtime[173:903] NSDocumentController's invocation of -[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:] returned nil for NSAutosavedInformationDirectory. Here's the error:
Error Domain=NSCocoaErrorDomain Code=642 UserInfo=0x70147a0 "You can???t save the file ???Autosave Information??? because the volume ???DeployStudioRuntime??? is read only." Underlying Error=(Error Domain=NSPOSIXErrorDomain Code=30 "The operation couldn???t be completed. Read-only file system")

I then found this tip in another post on the forum [url]http://www.deploystudio.com/Forums/viewtopic.php?id=288[/url]:

************************************************
I guess the next thing I would try is to start up using your netboot set and try to restore the disk using terminal and entering. 

"usr/sbin/asr" restore --source asr://your.mcastserver.address:7800  --target /dev/disk0s2 --erase --puppetstrings --noprompt

and see if you have any luck with this.   In the target you can either enter the dev like this or enter the volume such as /Volumes/Macintosh\ HD

and see how that goes.
************************************************

I used asr to restore both of my multicast images. The 10.6.1 image restore without problem.

I'm still getting a failure on the 10.5.8 production image in the same spot as the image is almost complete with asr giving this error message:

*************************************************
Server data rate exceeds client capability, or packet loss exceeds error correction ability.
Adjust server data rate and/or verify network integrity and try again.

Could not restore - Cannot allocation memory
XSTA fail

*************************************************

Dropping my data rate does not seem to be making any difference. The only thing I see happening there is that it's taking a longer time to reach the point of failure -- 69 minutes at 12 MB/s vs 34 minutes at 25 MB/s. Please keep in mind the unicast restore of this image completes in a little over 11 minutes. Could I have corruption in my image that could be causing the failure? Is something timing out before being able to resend the failed packages?

Thanks for any advice you may have,
Cheryl

Offline

#2 2009-11-08 23:10:56

applesab
Member
Registered: 2009-11-08

Re: Multicast restore failing with XDBG failed requests

Hi, Cheryl.

My recommendation (and a general recommendation for all Mac OS X images for use with multicast ASR):

-- After creating your images via DSS, ALWAYS re-convert them to UDZO (even if they already are UDZO) using the hdiutil convert function.

hdiutil convert my_image.dmg -format UDZO -o my_fixed_image.dmg

-- After re-converting to UDZO (even if it was UDZO already), re-run ASR imagescan

and then use the re-converted, re-scanned DMG file with DSS.

If you do the two steps above (don't skip the hdiutil convert step!), you should be able to get excellent data rate numbers and, in fact, be able to push your data rate higher than you had in the past.  Remember...the goal is not to finish with no XBDG messages.  The goal is that you should finish with less than 32MB (megabytes) of lost packets.  But if you don't do the two steps above, even one lost packet can sink you.

Finally, keep in mind that the "sweet spot" for multicast's speed advantage is when you are restoring 15+ clients at a time.  If you are doing one-off restores, unicast is going to almost always be faster.

Offline

#3 2009-11-09 20:36:57

CherylT
Member
Registered: 2009-10-02

Re: Multicast restore failing with XDBG failed requests

Hello,

I used the hdiutil convert command + ASR imagescan as described above on the image I was having trouble with and it restored without any XDGB failed requests and DS finished the Multicast restoration without errors.

What is UDZO?

Cheryl

Offline

#4 2009-11-10 01:52:57

applesab
Member
Registered: 2009-11-08

Re: Multicast restore failing with XDBG failed requests

If you look at:

man hdiutil

you will see that UDZO refers to the format of the disk image. 

Specifically, UDZO is what is known as a UDIF zlib-compressed image.  Glad to see this worked out for you!

Offline

Board footer

Powered by FluxBB