DumbDD
- Thread starter Snial
- Start date
I could be incorrectly crossing over two separate discussions, but that was what I was trying to work out. A bit of jiggery-pokery on a modern machine to pre-tweak the image and a raw disk write could be the solution to all this.
Should run in 6.0.4(ish) and up but it's untested on anything other than 7.5.5
Well it shouldn't but this is hot code so I'm not comfortable saying it definitely will not. It seems unlikely unless the OS maps IDE devices onto SCSI IDs or something like that.
Would be prudent to have anything important backed up just to be on the safe side, but obviously that advice applies to any system (not great about following it myself)
Correct!
That's the idea.
The whole installation is on 3 CDs. So, the first .iso would contain the normal .iso partition table and the PA-RISC system should boot from it and won't see the other CDs, but that's fine.
For the Debian installation, I understand that the first .iso is the core installation and the other(s) are additional packages. So, I think it should be possible to mount those on reboot based on the sector offset and then install the packages.
So, I was thinking this would be reasonable, because I did something similar when playing with a MAME-based SparcStation 1 emulator on my Mac mini 2012. I couldn't get the FD to work, but I could create a HD image with a missing partition; then mount that missing partition from within SunOS and dd to it. Then I could shutdown and from the host side, dd the data back out. It was very crude, but worked. In the future I plan to use the emulated ethernet to transfer data, now that I have a better grasp of how to link it up to virtual network interfaces on the Mac.
But thinking about it again, I might be wrong, or at least a bit wrong. I would need to mount the other .iso images as .iso's so that the target (the PA-RISC system) understands their partition maps too. Maybe that's reasonable: the other .iso s on the HD won't be on partitions on the HD, so it's not like it's partitions within partitions.
It does mean that DumbDD needs to be able to specify the target offset, which I hadn't considered earlier... though I could get around that too just by joining them all together. However, I might not do that as I might not want to write 2GB in one go, just 644MB at a time.
Are you sure the merge script doesn't just extend the first image and move the package files onto it?
The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.
Aaah, OK. I'd looked at the web page talking about this and then forgot about it. So, perhaps that solves one problem: it results in a merged .iso . In this case, the .iso would be about 1.932GB I think, less than 2GB. Sorry about that.
This is from:
OK, I have a related question: I'm planning to put 3x 650MB Debian .iso's onto a single 2.1GB SCSI HD (an actual SCSI HD) as a single image. There's a web page telling me how to merge the .iso's:
wiki.debian.org
However, my PowerBook 1400 is my only properly working SCSI Mac. So, the workflow is:
DebianIsoDownloads -> Mac mini i5 -> CF Card -> PowerBook 1400c -> External SCSI HD.
Now, with Mac OS X I could use
MergeDebianIsos - Debian Wiki
However, my PowerBook 1400 is my only properly working SCSI Mac. So, the workflow is:
DebianIsoDownloads -> Mac mini i5 -> CF Card -> PowerBook 1400c -> External SCSI HD.
Now, with Mac OS X I could use
dd to copy the .iso's block by block. I'm not sure what I should use with Mac OS 8.1. I certainly don't want a partition table...Of course, where it says: "I certainly don't want a partition table", it means I don't want an Apple Partition Table, the original .iso partitions are fine and expected.
I was thinking it would be strange if it didn't and the description on the page sounded like it did.
It should save properly, as it would be interpreted as an entire disk.
If the iso is from a CD, then the resulting .img might be suitable only as a CD.
I would examine the partition map of the disk image using dumpvols.sh on macOS to see if it makes sense for a CD or HD.
CDs might have block size of 2048 while HDs have block size of 512.
I've seen partition maps that support both block sizes.
honestly for that specific task i'd suggest using a Zulu-Compatible SCSI Emulator in initiator mode
For fun I wrote a version of DumbDD in THINK C 5. It's <4kB and fairly crude. I transcribed the Forth routines from MacTech I linked earlier, but I have almost certainly made mistakes. I tried it on miniVMac with the actual SCSI writes blocked out (and a delay of 2/60ths of second between each sector) so I could watch it update, but the version of Dd and the project attached would do it for real (find the #if 1 in the .c and turn it to #if 0 to reenable dummy writes). I tried to try it on InfiniteMac emulating a PM6100, but I mucked something up and now it won't boot properly with Saved HD. It thinks there could be another instance in a different tab using it, but there isn't another Infinite Mac tab and I don't know how to find and delete the Saved HD cache file ( @mihai , @joevt I'm sure you know). Also the BlueSCSI support crashes now, so I don't think I can get anything in or out. I'm not yet brave enough to try it on a real Mac.
You can quit mid-way by choosing File:Quit, or by closing the window. Progress updates every 0.5s. I think I'll change Dd:Copy to Dd:Transfer, because obviously Copy belongs on the Edit menu, but I didn't want Dd to be considered an 'Edit'. You can do stupid things like switch the SCSI device mid-transfer and it will happily trash another disk half way through, so take care! In future updates I would disable those menu options during transfer, add a Filename and SCSI ID to the window update (and maybe a progress bar). I would also support Option+'.' to stop a transfer without quitting and/or Dd:Stop .
Here's the app and project as it currently stands.
You can quit mid-way by choosing File:Quit, or by closing the window. Progress updates every 0.5s. I think I'll change Dd:Copy to Dd:Transfer, because obviously Copy belongs on the Edit menu, but I didn't want Dd to be considered an 'Edit'. You can do stupid things like switch the SCSI device mid-transfer and it will happily trash another disk half way through, so take care! In future updates I would disable those menu options during transfer, add a Filename and SCSI ID to the window update (and maybe a progress bar). I would also support Option+'.' to stop a transfer without quitting and/or Dd:Stop .
Here's the app and project as it currently stands.
I was able to 'recover' the Saved HD by restarting Safari, and do some more tests that involved copying about 6MB to it. Strangely though it never seems to corrupt the Saved HD itself, which puzzles me (I expected DumbDD to scribble over the HD making it unreadable). Actually it doesn't. These days I'm using the Snow Mac IIcx emulator, because I understand it has a proper SCSI device emulator and my app is 68K anyway, so it should be fine.
I've modified DumbDD so in theory it can read from SCSI drives as well as write to them. This means it should be possible to write to a SCSI drive; read it back into a file and then compare them. I also added a '•' mark to the SCSI menu so you can see which SCSI ID you're writing to; a File:Save... menu option to specify the file to save to; Dd:From... and a Dd:Blocks... dialog so you can tell DumbDD how many blocks you want to read. Finally I changed Dd:Copy... to Dd:To... because Copy would belong on the (non-existent) Edit menu. Finally, I implemented option+'.' so that you could stop a Dd operation without having to quit the application. I added safeguards so that Dd:To... and Dd:From... were disabled if you hadn't provided the right data (a SCSI ID and an open file for Dd:To... and a SCSI ID, a Block count and a file to save to for Dd:From... .)
So, in theory it's much more usable. However, when I try and read from SCSI via Infinite Mac's Snow Mac IIcx emulator, I get:
I don't know how it's possible to do both, particularly since a device header, surely is in emulator RAM and the disk is the disk? Here's the relevant snips of code just in case anyone can see the obvious error (which I can't yet):
It works in dummy transfer mode though, I can create files of the right number of blocks containing whatever was in gScsiBuf. I guess people know a lot more about raw SCSI transfer than I do? It's currently 5.14kB long!
Ironically although I've not been able to scramble Saved HD on infinite Mac, I did manage to corrupt the System Folder on my miniVMac during some early testing of Dd:From..., forcing me to copy a System 6.0.8 from another HD image. I've now clocked up more System 6 experience than I've ever had in my whole life!
The current project and application (including the DumbDDDummy version, which doesn't actually read or write to SCSI drives) is attached.
I've modified DumbDD so in theory it can read from SCSI drives as well as write to them. This means it should be possible to write to a SCSI drive; read it back into a file and then compare them. I also added a '•' mark to the SCSI menu so you can see which SCSI ID you're writing to; a File:Save... menu option to specify the file to save to; Dd:From... and a Dd:Blocks... dialog so you can tell DumbDD how many blocks you want to read. Finally I changed Dd:Copy... to Dd:To... because Copy would belong on the (non-existent) Edit menu. Finally, I implemented option+'.' so that you could stop a Dd operation without having to quit the application. I added safeguards so that Dd:To... and Dd:From... were disabled if you hadn't provided the right data (a SCSI ID and an open file for Dd:To... and a SCSI ID, a Block count and a file to save to for Dd:From... .)
So, in theory it's much more usable. However, when I try and read from SCSI via Infinite Mac's Snow Mac IIcx emulator, I get:
I don't know how it's possible to do both, particularly since a device header, surely is in emulator RAM and the disk is the disk? Here's the relevant snips of code just in case anyone can see the obvious error (which I can't yet):
C:
SCSIInstr gScsiProg[kScsiProgLen]={
{ scNoInc, 0UL, 0UL },
{ scStop, 0UL, 0UL }
};
#define Wrd(aWord) ((uint8_t)((aWord>>8)&255)), ((uint8_t)(aWord&255))
#define Lng(aLong) ((uint16_t)((aLong>>16)&0xffff)), \
((uint16_t)(aLong&0xffff))
uint8_t gReadBlk[]={
6, 8, Wrd(0), 0, 0, Wrd(0),
};
uint8_t gWriteBlk[]={ // offsets 2, 3, 4 are the block num (big-endian)
6, 0xa, Wrd(0), 0, 0, Wrd(0),
};
void ScsiInit(short aId, uint8_t *aCmdBlock)
{
SCSIGet();
SCSISelect(aId);
SCSICmd((char*)&aCmdBlock[1], *aCmdBlock);
}
short ScsiFinish(int16_t *aRetMsg, uint32_t aDelay)
{
SCSIComplete(&gScsiStat, &gScsiMess, aDelay);
*aRetMsg=gScsiMess;
return gScsiStat;
}
void ScsiProgSet(SCSIInstr *aProg, uint8_t *aBuff, uint32_t aBytes)
{
aProg->scParam1=(uint32_t)aBuff;
aProg->scParam2=(uint32_t)aBytes;
}
short ScsiDoRead(int16_t *aRetMsg, uint32_t aTicks,
short aId, uint8_t *aCmdBlock,
uint8_t *aBuff, uint32_t aBytes)
{
ScsiInit( aId, aCmdBlock);
ScsiProgSet(gScsiProg, aBuff, aBytes);
SCSIRead((Ptr)gScsiProg);
return ScsiFinish(aRetMsg, aTicks);
}
short ScsiDoWrite(int16_t *aRetMsg, uint32_t aTicks,
short aId, uint8_t *aCmdBlock,
uint8_t *aBuff, uint32_t aBytes)
{
ScsiInit( aId, aCmdBlock);
ScsiProgSet(gScsiProg, aBuff, aBytes);
SCSIWrite((Ptr)gScsiProg);
return ScsiFinish(aRetMsg, aTicks);
}
tRawCopyInfo gRawCopyInfo;
void ScsiRawCopyInit(tRawCopyInfo *aInfo, uint16_t aId, int16_t aState)
{
aInfo->iBlkPos=0UL;
aInfo->iId=aId;
if((aState&kRawCopyEventScsiOpMask)==kRawCopyEventScsiWrite) {
GetEOF(aInfo->iFd, &(aInfo->iLen));
}
else {
SetFPos(aInfo->iFd, fsFromStart, 0UL); // reset the file.
}
aInfo->iLenBlks=(aInfo->iLen+kBlkSize-1)>>kBlkSizeBits;
aInfo->iState=aState; //kRawCopyEventGo;
}
//#define kScsiRawCopyDummy
void ScsiRawCopy(tRawCopyEvent aEvent /* oops, unused*/ )
{
register tRawCopyInfo *info=&gRawCopyInfo;
int32_t count;
OSErr err=0;
int32_t to=In(kUpdateRate);
while(info->iLen && !After(to)) {
tBool readOp=(info->iState&kRawCopyEventScsiOpMask)==
kRawCopyEventScsiRd;
uint8_t *blkCmd=readOp? gReadBlk:gWriteBlk;
count=kBlkSize;
blkCmd[2]=(uint8_t)(info->iBlkPos>>16);
blkCmd[3]=(uint8_t)(info->iBlkPos>>8);
blkCmd[4]=(uint8_t)(info->iBlkPos&255);
if(readOp) {
#ifndef kScsiRawCopyDummy
ScsiDoRead(&gScsiMess, kStdWait, info->iId, blkCmd,
gScsiBuf, kBlkSize);
#endif
err=FSWrite(info->iFd, &count, gScsiBuf); // gScsiMess, gScsiStat
}
else {
FSRead(info->iFd, &count, gScsiBuf); // gScsiMess, gScsiStat
#ifndef kScsiRawCopyDummy
ScsiDoWrite(&gScsiMess, kStdWait, info->iId, gWriteBlk,
gScsiBuf, kBlkSize);
#endif
}
#ifdef kScsiRawCopyDummy
{
int32_t to=In(2);
while(!After(to)) {
// Delay 2 ticks.
}
}
#endif
++info->iBlkPos;
if(err==noErr && info->iLen>kBlkSize) {
info->iLen-=kBlkSize;
}
else {
info->iLen=0;
}
}
if(info->iLen==0) {
FSClose(info->iFd);
info->iState=kRawCopyEventDone;
info->iFd=0; // Reset FD.
AppMenuDDEnable(info);
}
}It works in dummy transfer mode though, I can create files of the right number of blocks containing whatever was in gScsiBuf. I guess people know a lot more about raw SCSI transfer than I do? It's currently 5.14kB long!
Ironically although I've not been able to scramble Saved HD on infinite Mac, I did manage to corrupt the System Folder on my miniVMac during some early testing of Dd:From..., forcing me to copy a System 6.0.8 from another HD image. I've now clocked up more System 6 experience than I've ever had in my whole life!
The current project and application (including the DumbDDDummy version, which doesn't actually read or write to SCSI drives) is attached.
That's an Infinite Mac error message. It's not from Snow. That's a bug for @mihai to fix.
I think device header means the part of the virtual SCSI HD that is not the HFS or HFS+ partition? i.e. the Apple Partition Map which is generated programatically if a disk image does not contain an Apple Partition Map.
I suppose you can work around this by changing your code to not use block ranges that cross partition boundaries? That means you need to have code that understand the Apple Partition Map. Or you would have to read one block at a time, which is probably slow.
OK, I'll add a Dd:Blocks... field to support starting blocks, then I can get it to read or write into the middle (or near the end) of the HD image and skip the APM. Though, actually it should indeed be possible to read the Apple Partition Map. TattleTech seems to work, I used it to get the SCSI IDs for the drives, but it also seems to return quite a lot of data I'd only expect from making direct SCSI commands.
I didn't say you could not read the Apple Partition Map. I said that you cannot read from the Apple Partition Map and from the next partition in the same command.
Below is output from my fork of DingusPPC. MetaImgFile lets you construct a virtual disk comprised of multiple disk images by constructing a partition map in RAM. Each part of the virtual disk is a "chunk". In this example, there are 7 chunks. The first chunk is in RAM and contains the constructed Apple Partition Map and the Mac OS 9 drivers. The next 5 chunks are disk images that each contain their own Apple Partition Map which is not included in the virtual hard disk. The last chunk "Infinite HD" is from a disk image that does not have a Apple Partition Map. MetaImgFile handles reads and writes that span chunks. EmulatorWorkerDeviceImageDisk in Infinite Mac does not?
So if you want to implement the suggested work around then you can try parsing the Apple Partition Map. The device header probably ends where the first non-driver partition begins. This is slightly more involved than what I said earlier - I said the device header ends after the partition map but I think it ends after the last driver partition.
Code:
( 0.304s) metaimgfile.cpp:246 INFO| . . { MetaImgFile: Open "/Volumes/Devs/SheepShaver/Disks/Data1.dmg".
( 0.308s) metaimgfile.cpp:246 INFO| . . { MetaImgFile: Open "/Volumes/FreeSpace/Data2.dmg".
( 0.314s) metaimgfile.cpp:246 INFO| . . { MetaImgFile: Open "/Volumes/FreeSpace/PowerMac8600SSD/PowerMac8600SSD.dmg".
( 0.316s) metaimgfile.cpp:246 INFO| . . { MetaImgFile: Open "/Volumes/FreeSpace/B&WG3Clone.dmg".
( 0.317s) metaimgfile.cpp:246 INFO| . . { MetaImgFile: Open "/Volumes/FreeSpace/140GiB.dmg".
( 0.317s) metaimgfile.cpp:246 INFO| . . { MetaImgFile: Open "/Volumes/Work/Programming/infinite-mac/InfiniteHD.dmg".
APM Block 0 contents
000: sbSig : 'ER' = sbSIGWord
002: sbBlkSize : 512
004: sbBlkCount : 741067092 = 379426 MB = 361849 MiB
012: DDMap[0]: 23 @ 64 0x0001 = kDriverTypeMacSCSI
01a: DDMap[1]: 36 @ 120 0xffff = kDriverTypeMacSCSIChained
022: DDMap[2]: 21 @ 176 0x0701 = kDriverTypeMacATA
02a: DDMap[3]: 34 @ 232 0xf8ff = kDriverTypeMacATAChained
Partition Map contents (48 partitions)
1: 63 @ 1 Type:"Apple_partition_map" Name:"Apple" Status:00000003=Valid,Allocated
2: 56 @ 64 Type:"Apple_Driver43" Name:"Macintosh" Status:00000103=Valid,Allocated,ChainCompatible BootSize:11286 BootCksum:0x0000F1F0 Processor:"68000" Pad:70744452 = 'ptDR' = kPatchDriverSignature
3: 56 @ 120 Type:"Apple_Driver43" Name:"Macintosh" Status:00000303=Valid,Allocated,ChainCompatible,RealDeviceDriver BootSize:18142 BootCksum:0x0000040F Processor:"68000" Pad:00010600 = kSCSIDriverSignature
4: 56 @ 176 Type:"Apple_Driver_ATA" Name:"Macintosh" Status:00000103=Valid,Allocated,ChainCompatible BootSize:10490 BootCksum:0x00007EB4 Processor:"68000" Pad:70744452 = 'ptDR' = kPatchDriverSignature
5: 56 @ 232 Type:"Apple_Driver_ATA" Name:"Macintosh" Status:00000303=Valid,Allocated,ChainCompatible,RealDeviceDriver BootSize:17254 BootCksum:0x00003417 Processor:"68000" Pad:77696b69 = 'wiki' = kATADriverSignature
6: 512 @ 288 Type:"Apple_FWDriver" Name:"Macintosh" Status:00000003=Valid,Allocated
7: 512 @ 800 Type:"Apple_Driver_IOKit" Name:"Macintosh" Status:00000003=Valid,Allocated
8: 512 @ 1312 Type:"Apple_Patches" Name:"Patch Partition" Status:00000003=Valid,Allocated
9: 2095328 @ 1824 Type:"Apple_HFS" Name:"disk image" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
10: 39062496 @ 2097152 Type:"Apple_HFS" Name:"disk image" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
11: 4 @ 41159648 Type:"Apple_Free"
12: 2097152 @ 41159652 Type:"Apple_HFS" Name:"MacOS9.1" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
13: 2097152 @ 43256804 Type:"Apple_HFS" Name:"MacOS9.2" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
14: 2097152 @ 45353956 Type:"Apple_HFS" Name:"MacOS9.2.2" Status:C0000031=Valid,Readable,Writeable,MountedAtStartup,Startup
15: 262144 @ 47451108 Type:"Apple_Free"
16: 1835008 @ 47713252 Type:"Apple_HFS" Name:"System7.5.3" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
17: 409600 @ 49548260 Type:"Apple_HFS" Name:"System7.5.5" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
18: 614400 @ 49957860 Type:"Apple_HFS" Name:"System7.6.1" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
19: 614400 @ 50572260 Type:"Apple_HFS" Name:"MacOS8.0" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
20: 614400 @ 51186660 Type:"Apple_HFS" Name:"MacOS8.1" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
21: 614400 @ 51801060 Type:"Apple_HFS" Name:"MacOS8.5" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
22: 614400 @ 52415460 Type:"Apple_HFS" Name:"MacOS8.5.1" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
23: 614400 @ 53029860 Type:"Apple_HFS" Name:"MacOS8.6" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
24: 14773192 @ 53644260 Type:"Apple_Free"
25: 16778400 @ 68417452 Type:"Apple_HFS" Name:"Jaguar" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
26: 160 @ 85195852 Type:"Apple_Free"
27: 31457280 @ 85196012 Type:"Apple_HFS" Name:"Panther" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
28: 62914560 @ 116653292 Type:"Apple_HFS" Name:"Tiger" Status:4000007F=Valid,Allocated,InUse,Bootable,Readable,Writeable,BootCodePositionIndependent,MountedAtStartup LgBootStart:24279928 BootSize:417792 Processor:"powerpc"
29: 267616 @ 179567852 Type:"Apple_Free"
30: 95764008 @ 179835468 Type:"Apple_HFS" Name:"Misc8" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
31: 20971520 @ 275599476 Type:"Apple_HFS" Name:"Big Clone2" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
32: 12582912 @ 296570996 Type:"Apple_HFS" Name:"MacOS9 Clone2" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
33: 14680064 @ 309153908 Type:"Apple_HFS" Name:"Jaguar Clone2" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
34: 16777216 @ 323833972 Type:"Apple_HFS" Name:"Panther Clone2" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
35: 20971520 @ 340611188 Type:"Apple_HFS" Name:"Tiger Clone2" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
36: 81787104 @ 361582708 Type:"Apple_HFS" Name:"Leopard" Status:40000031=Valid,Readable,Writeable,MountedAtStartup
37: 29360118 @ 443369812 Type:"Windows_FAT_32" Name:"FATPART" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
38: 29360128 @ 472729940 Type:"Apple_HFS" Name:"partHFS2" Status:C0000033=Valid,Allocated,Readable,Writeable,MountedAtStartup,Startup
39: 29360128 @ 502090068 Type:"Apple_HFS" Name:"Untitled 3" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
40: 29360128 @ 531450196 Type:"Apple_HFS" Name:"Untitled 4" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
41: 29360128 @ 560810324 Type:"Apple_HFS" Name:"Untitled 5" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
42: 29360128 @ 590170452 Type:"Apple_HFS" Name:"Untitled 6" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
43: 29360128 @ 619530580 Type:"Apple_HFS" Name:"Untitled 7" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
44: 29360128 @ 648890708 Type:"Apple_HFS" Name:"Untitled 8" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
45: 29360128 @ 678250836 Type:"Apple_HFS" Name:"Untitled 9" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
46: 29360128 @ 707610964 Type:"Apple_HFS" Name:"Untitled 10" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
47: 10 @ 472729930 Type:"Apple_Free"
48: 4096000 @ 736971092 Type:"Apple_HFS" Name:"Infinite HD" Status:40000033=Valid,Allocated,Readable,Writeable,MountedAtStartup
Chunks
1824 @ 0 bytes:[0 933888) offset:0
2095328 @ 1824 bytes:[933888 1073741824) offset:933888
39062500 @ 2097152 bytes:[1073741824 21073741824) offset:32768
234439824 @ 41159652 bytes:[21073741824 141106931712) offset:933888
167770336 @ 275599476 bytes:[141106931712 227005343744) offset:933888
293601280 @ 443369812 bytes:[227005343744 377329199104) offset:32768
4096000 @ 736971092 bytes:[377329199104 379426351104) offset:0Can you set the copy block size to 512 bytes @Snial? Then the boundaries will almost always match.
Similar threads
