AssistReq: Virtual drives have bad clusters?

[odysseus654]

I'm trying on trying to get my wife's old Win98 machine up and running on VirtualBox. I think I've managed to clean most of the junk out (wish Ad-Aware was still willing to give me updates), but I'm having problems with ScanDisk finding a large number of bad clusters near the end of the disk.

This drive was rather painfully copied from the original machine using a program that I found out could not handle drives over 4 GB in size (it would start overwriting the beginning of the drive at that point) so the image I originally got was pieced together and rather approximate in size (the file ended up being 4310046720 bytes long). At that time I was successfully running the drive under Bochs with "cylinders=8221, heads=16, spt=64", the new version of Bochs is refusing to start with these parameters however ("invalid hard drive size parameters")

I converted the image file over to a VDI using a utility called CloneVDI-1.40, it reports "last-CHS: c=523,h=254,s=63; num-sectors=8417997". VirtualBox reports it as 4.01 GB

So, have i completely fubarred the translation here? I'm hoping to not have to go back again to the raw copied image (that was a lot of cleanup I did), do I create a fresh new drive image and do a sector copy of the contents? Do I open up the VDI file with a hex editor and modify the header info?

[odysseus654]

Okay, if it helps I just found the VirtualBox log (which I prob should have looked more closely at). It appears to report 8417280 sectors on the drive (which is significantly less than the 8417997 sectors in the partition?) The "failed clusters" seem to correspond to "rc=VERR_INVALID_PARAMETER" disk errors in the log...

In the end, I'm not really sure how big this hard drive is supposed to be (anyone know how to do LBA translations?), I'm still thinking that something in the VDI header needs hex-edited (or I need to sector-copy into a properly-constructed VDI?)

[mpack]

At that time I was successfully running the drive under Bochs with "cylinders=8221, heads=16, spt=64"

I'm surprised you got away with that, since AFAIK the SPT value is illegal - it should be 63 max (and ever since LBA was invented, AFAIK it should be 63 period). The fact that your partition extends beyond the end of the drive would be a pretty good explanation for the disk errors. Given the file size you mention, I would expect the correct (virtual) geometry to be CHS=(524,255,63).

Ideally you should convert the original raw file again, as I suspect the VDI may be hosed. What kind of onerous "cleanup" were you talking about btw?

Final note: AFAIR, CloneVDI doesn't report the number of sectors on the drive anywhere. It does report the number of sectors used by a partition, which is often less than the size of the drive.

Final final note: this was a drive image right? - Not just a partition image?

[odysseus654]

Yes, this was a drive image (thus the partition table that CloneVDI was able to read). I've converted multiple times from the raw image so far and they all exhibit the kind of issues, although (and this has not been verified yet) I don't believe that I have actually lost data in the nonexistant part of the drive yet (it may have been unused)

The cleanup work I'm talking about is about 2 weeks worth of force-uninstalling and in general making the system usable again; my wife had a number of unsavory programs installed and running, a couple of which came bundled with her system and had her computer's brand name on it. This is like the 2nd or 3rd attempt at it and I'm almost done I think (the last time windowsupdate apparently fubarred the system, this time I'm taking very generous snapshots). Unfortunately I'm not that familiar with any current AV or anti-adware that targets Win9x machines these days.

I figure that CloneVDI has to figure out the size of the drive *somewhere* as it needs to be stored in the VDI. I'm more likely to consider that the raw flat drive length is somehow confusing things (like i said, it was very messy trying to get it, at the moment I'm remembering the running machine transferring its own hard drive over an ethernet crossover cable using a program that obviously never heard of files larger than 4 GB)

From this I'm still thinking that I need to create a new fixed-length VDI of the proper size, then attach it to linux and run "cp /dev/hdc /dev/hdd" or something?

[TerryE]

it should be 63 max (and ever since LBA was invented, AFAIK it should be 63 period)...I would expect the correct (virtual) geometry to be CHS=(524,255,63)...

Not quite. There are sound reasons for doing what I do which is to set the geometry to CHS=(N,128,32) and the VDI size to (1024N-128)Mb. That way the cylinders are VDI block aligned and the virtual file systems clusters are host file system cluster aligned. Perhaps I am a bit anally retentive but it does make a few % improvement on I/O performance.

[odysseus654]

Well, I do know that a CHS of (h=254,s=63) is a "fake" CHS (or LBA-encoded CHS?), I'm still not sure what the mapping is, but I'll do a bit of googling.

I did try to create a new hard drive in VirtualBox of size 4310046720 (524*255*63*512), but according to the logs the drive has the same size as the one I'm currently having trouble with (reported as 8350/16/63 = 4309401600)

I'll try to get a "real" CHS partition size here, but this is starting to sound like I'm running into a disk size rounding issue in VB?

Edit: If I change #heads from 255 to 256, then the original drive CHS i think comes to 8384/16/63. Will try another drive...

[odysseus654]

Okay, I did create a new drive, then used an Ubuntu linux LiveCD to do a "cp /dev/sda /dev/sdb" (probabaly overkill, next time I'm using a smaller liveCD). Scandisk appears to be okay with the result, I just completed a surface scan.

It appears as though this was self-inflicted a long time ago, for some reason when I was assembling the pieces of the raw drive I figured that the number of bytes in the hard drive was C * H * S * 512; the LBA translation kicked me as I should have used "256 heads" where I saw "255 heads" in that formula.

I'm not sure how to dictate the geometry that VirtualBox uses in its drives, I have tried to give it an exact number of bytes when creating the drive, but it looks like it reduced my request by two cylinders (8384/16/63 -> 8382/16/63, or 1024 sectors), at least according to what I see in the log files (which is the only place that I can find drive geometry stated). It seems to be big enough though, or I would have seen errors by now.

Unless something comes up I think this request has been resolved at this point though.

Now to await for Win9x client extensions

[mpack]

There are sound reasons for doing what I do which is to set the geometry to CHS=(N,128,32) and the VDI size to (1024N-128)Mb. That way the cylinders are VDI block aligned and the virtual file systems clusters are host file system cluster aligned.

Nice trick, but if CloneVDI is used to create the VDI then you get that for free - it adjusts the VDI header size to ensure that the first sector of the first partition falls on a 4K file boundary.

[TerryE]

...CloneVDI is used to create the VDI then you get that for free - it adjusts the VDI header size to ensure that the first sector of the first partition falls on a 4K file boundary.

Yup but by default the first partition starts at track 1 which is LBN 63 and with its cluster 0 being LBN 63-66 so bang goes the cluster alignment. If you set the track size to 32 then it starts at 32.

@odysseus654, read up the wikipedia MBR article and use fdisk in advanced mode to see what is going on in your virtual MBR. The virtual BIOS picks up the SPT from the MBR as does the booting OS.

[mpack]

Yup but by default the first partition starts at track 1 which is LBN 63 and with its cluster 0 being LBN 63-66 so bang goes the cluster alignment.

I'm not sure what you are saying. As far as I'm aware, filesystem clusters are aligned with the start of a partition, not with the start of a track. It may be true that partition tools usually align partitions with track boundaries, but the filesystem inside the partition generally doesn't know or care about that. To be honest I'm not absolutely certain how FAT and EXTx will handle this, but certainly NTFS doesn't care about track boundaries - it uses LBA addressing over the entire image. Hence if the start of a partition is aligned on a host cluster boundary then guest clusters will map one-to-one with host clusters (assuming both are using compatible cluster sizes of course).

[TerryE]

What I am saying is that

• Yes, filesystem clusters are aligned with the start of a partition
• AFAIK all partitioning tools align partitions with HDD a cylinder track 0, except the first partition which is aligned to logical track 1 and the logical partitions in an extended partition which are also just track aligned.
• There was some logical reasoning for this in the past when the C/T/S addressing scheme was physical. However as you say under LBA addressing scheme the convention is that TPC=255 and SPT=63 giving a SPC of 255x63 = 16,065 sectors per (logical) cylinder or 8,225,280 bytes per cylinder but for absolutely no logical reason now.
• So on my laptop for example I have two partitions (NTFS system + data) for XP and two (Ext4 + LVM) for Ubuntu 64 with sizes 2611, 5222, 1305, 21263 cylinders.
• NTFS, Ext3, Ext4 all use by default a cluster size of 4096 (8 sectors).
• Because of this 63 / 16065 alignment partition 0 will never be 8 sector aligned. The subsequent physical partitions will only be 8 sector aligned if the previous partitions add up to a multiple of 8 cylinders.

This is why I use a cylinder size of 4096 sectors per cylinder inside my VDIs. This way clusters in the guest file systems will be aligned to clusters in the containing host file system.