Hi
see attachment ...
### script to manually extract a flat file to a new location
### please set the IF parameter
### please check the OF parameter
### put script into a new directory for the VM
### make script executable and run it
### if you run the script via putty launch it as "nohup script &"
IF="/dev/disks/naa.blabla"
OF="onion_1-flat.vmdk"
### (268435456000 bytes in size)
dd if=$IF of=$OF bs=1M conv=notrunc seek=$(( 0 / 1048576 )) count=$(( 1048576 / 1048576 )) skip=$(( 245236760576 / 1048576 )) >> copy.log ### 245237809152)]
exit
...
I usually stop the script after the first MB.
Copy the first MB to your Linux-admin host and run
sgdisk -p onion_1-flat.vmdk
That should display a reasonable partitiontable if you got the IF-parameter entered correctly.
When that looks good remove the exit line.
Here are 2 lines from somewhere in the original txt file:
[ 1695547392: 1048576] --> [VMFS -- LVID:5b1e3f9b-90303408-edc2-001fc69c00f3/5b1e3f9b-8dd148de-4cc8-001fc69c00f3/1😞 245248294912 --> 245249343488)]
[ 1696595968: 32505856] --> [NOMP -- 
0 --> 32505856)]
red values > seek parameter
blue values > skip parameter
green values > count parameter
bold black parameters > if parameter - where you do not need to add that line when if=/dev/zero (NOMP)
The skip parameter is always zero as it will not make a difference when if=/dev/zero
Watch out if you use VMFS-volumes with extents !!!
Do resist the tempation to combine 100 of 1 MB fragments into one 100Mb fragment.
If one of those 1 MB fragments has an I/O error it will prevent the 100Mb to copy.
If you consider to not convert the bytes values into full MBs the script will be dead slow.
Dont consider to use larger blocksizes to speed up the extraction.
larger bs-values will not speed up the process and and introduce several other new problems ... tried it and changed back to 1MB blocksizes.
Ulli
