HDD GURU FORUMS

hi,
Possibly a dumb question that I havent thought about enough.

1. I write a pattern to the whole disk.
2. I tak an image of that disk with Partition Find and Mount.
3. I run HxD as administrator, and open both the image file and the physical Flash Disk that is still plugged in.
4. Tile both windows and scroll them both to the end.

Why is there a size difference?

in every instance there has been a huge size difference. sometimes drive shows bigger sometimes image.

Whats going on?

on case and below some others..

AIUI, PF&M would be taking an image of the partition (logical drive) rather than the physical drive.

I would examine sector 0 in each case. Is it an MBR or is it a boot sector? Does the capacity reported in sector 0 match the size of the PF&M image?

I am writing the pattern with SC Pattern Writer app. I don't believe it writes a partition as after it is written, windows wants to format it.

The capacity of the flash drive is being rounded down to the nearest whole cylinder.

63 sectors per track
255 heads per cylinder

15197490 = 946 x 255 x 63
(15 204 351 - 15 197 490) / (255 x 63) = 0.427

16209585 = 1009 x 255 x 63
16214016

31262490 = 1946 x 255 x 63
31277056

15101100 = 940 x 255 x 63
15100256

15502725 = 965 x 255 x 63
15515648

@fzabkar: if HaQue write pattern on flash, there is only pattern. No MBR, no FAT etc. Only 77 pattern sector.

Haque: make dump image with DMDE for example, but choose physical device, not partition.

OK will try it and report.

So the DMDE image shows the same last sector as the Physical Disk as I think it should. For some reason the Partition Find and Mount image is different. I don't know it the PFaM people have a different take on what to image, or if it is a bug. I will send of a question to them with my results and ask if that is by design, or if they have any insight. It is possible they don't support what I am doing, as the software is about finding partitions, not working in the absence of one. Or that the do something along the lines of what fzabkar has said. The do have a caveat after all..

When Find & Mount tool does not work
Partition Find & Mount software is designed to find lost or deleted partitions in the most convenient way, however, it may not work if the file system on a partition or hard drive itself is severely damaged.

This is the Physical disk opened in HxD Hex Editor, and the next pic is a comparison of the 2 images I took, first PFaM and secon DMDE.





some other info:

Size of physical drive = 3 913 344 LBAs

Using DMDE's two CHS combinations ...

243 x 255 x 63 = 3 903 795
970 x 64 x 63 = 3 911 040

It appears that PF&M is using the first set of CHS values. IIUC these values are coming from the SCSI driver.

Thanks franc, yes I agree with that, and also agree with the rounding down of the cylinder. Actually, looks like a FLOOR operation, which just strips anything after the decimal point. I was unable to track down any proper specifications that show it, but was able to find a few references to rounding, enough to say that this is probably the cause. It would make sense for reasons such as wanting an integer value, not a float when coding drivers, BIOS and software interfaces.

Many many many supposedly technical manuals have words like "may" might" "could" "depends" etc when talking about LBA / CHS, including this hilarious Gem

Code:

What is the real geometry? The easiest answer is that there is no such thing. And if there were, you wouldn't want to know, and certainly NEVER, EVER tell fdisk or LILO or the kernel about it. It is strictly a business between the SCSI controller and the disk. Let me repeat that: only silly people tell fdisk/LILO/kernel about the true SCSI disk geometry.



pages like this http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat

Code:

•Now Calculate the number of Cylinders for your SD Card.
#cylinders = FLOOR (the number of Bytes on the SD Card (from above) / 255 / 63 / 512 )So for this example:  2021654528 / 255 / 63 / 512 = 245.79.  So we use 245 (i.e. truncate, don't round).

and
http://eab.abime.net/showthread.php?p=938496

Code:

Next to get how many cylinders this is we should do first calculation from above in reverse

cylinders = bytes / (heads * blocks * 512) = 524288000 / (16 * 63 * 512) = 1015,873

from what I saw in practice it should be rounded down so


which, coincidentaly, was quite an interesting tangent

I think this puts the solved moniker on this