Please Help with removing bootloader (Ontrack DiskManager) from new HD

[DimViesel]

My relative (who, to save him from potential shame, shall remain nameless) attempted to install XP onto a brand new OEM Samsung SP1614N (160GB, ATA133, 8MB chache - one of, if not the best 160GB non SATA IMHO).
So? Lucky SOB right?
It should have been. Trying to get XP Pro installed onto this HD.
It should have been a piece of cake... however he may aswell have eaten the cake as being less than informed about setting up current PC hardware he downloaded Ontrack Diskmanager from Samsung's site & ran the tool installing onto this previously untouched Hard disk.
According to 'Everest@home Edition' his mobo is the MSI K7T266PRO.
Looking at the BIOS updates there is a mention of an update to rectify an issue with 160GB IBM drives but that is all.
I presume that this mobo is modern enough to cope with 160GB Hard drive volumes(?)

The issue now is that once XP has finished extracting/copying all the files for setup upon attempting to reboot Ontrack's Diskmanager MBR loaded utility interrupts the process or is outright fouling it up, causing errors in XP setup routine.
I learned that destroying all Partitions including the Primary does not clear the info in the MBR or wherever Ontrack software has written itself too.
What is really tragic?
This tool is a correction for a BIOS with an upper 32GB limit...
What is the correct way to remove these bootloaders?

[Áedán]

Bootloaders live in one place - the boot sector. Commands such as FixMBR or FDISK/MBR should be able to overwrite the existing bootsector.

Failing that, there are some utilities that can wipe the first 128 sectors of the disk to ensure that it looks like a brand new pristine disk.

[DimViesel]

I suspected that either you or Gizmo would lend their expertise to this one, thank you.

I guessed that it would require editing the Master Boot Record...
Got that far, but then lack of experience impeded me... never had to do this before - also tbh I am not clear if the MBR is written to the hard disk surface itself... "some utilities that can wipe the first 128 sectors of the disk to ensure that it looks like a brand new pristine disk" I take it that this means that it probably is & commonly occupies this (reserved) space.
Can you recommend one of the best tools for this Áedán?

(PS if you see this would you be kind enough to explain precisely why selecting certain partition dimensions during XP setup result in them being adjusted by a small number of MB sometimes, & the figure input being the accepted size at others? I have yet to find a theoretical or otherwise explanation of this - is it something to do with the rounding operation required of the partition creator? Also there seems to be a perpetual 8MB 'end' partition - what is this for?)

[Repo Man]

I would get Samsungs diagnostic software, available here, http://www.samsung.com/Products/Hard...ties/hutil.htm , and use it to low level format the drive. Then you can start with a clean slate.

[smidgley]

Run the Ontrack Diskmanager again and disable (remove) the drive overlay.

[Áedán]

The master boot record lives in the very first sector on the hard disk. It so happens that this sector ALSO contains the partition table.

As to your other question, when partitioning takes place, it's done on a track boundary, not a sector boundary. Technically, it's possible to do it on a sector boundary, but some OSes and partitioning programs take great offense to that, so it's not worth the hassle.

[DimViesel]

Sincerely, thanks to you all.
He has now managed to get XP installed. Thanks.
Are you saying that the result is arbitrary Áedán? That there is not efficiency in space used to be eked by selecting a certain partition size over another?
I guess my real question was:
Is there a factor for a partition size that is superior to others in terms of resultant capacity or efficiency for the filesystem or whatever etc... ?

[Áedán]

For NTFS, the size of the partition doesn't really make any difference. For FAT12/16/32, the story is slightly different, with smaller partitions resulting is less slack space. However, with drives the size they are now, it's not worth worrying about such things.

[DimViesel]

Thanks Áedán, I get what you are saying.
Can you point me to a web page or some other document that explains from first principles what the resultant slack space(?) for NTFS partitions of a certain size is to be?

[Áedán]

On a disk, the smallest block of data that you can address is a sector. A sector contains 512 bytes of information. If you read data from a disk, it *HAS* to be in 512 byte chunks, even if you only wanted one byte of information.

However, NTFS and FAT operate on the concept of 'clusters'. A cluster is a number of sectors, considered by the file system to be the smallest block. With FAT, the cluster size is determined by the maximum number of clusters available. For FAT16, that's 65,536 clusters. For FAT32, it's 268,435,445 clusters. Each cluster is made up of one or more sectors on the disk, so it has to be a multiple of 512bytes.

It's easiest to illustrate with FAT16. If the disk was 32MB in size, we have 65536 sectors on the disk. This makes it easy, as we can allocate one sector per cluster. However, if the disk was 64MB in size, we have 131072 sectors on the disk, so we have to allocate two sectors per cluster to keep the number of clusters at or below 65536. That gives you an idea to the concept of clusters.

For slack space, remember that the cluster is the smallest space that can be allocated on the disk. Lets say you have a file that's only 10 bytes long. You write it to disk, but the smallest space that can be allocated by the file system is 1024 bytes. Now your 10 byte file is taking up 1024 bytes of disk space! The 1014 bytes that are not being used are slack space. They cannot be used to store another file's information, as they make the smallest unit usable by the filesystem.

Now, the amount of slack space on a disk is dependant on the number of files and their size. If we make the assumption that each file will incur a random amount of slack space, then we can assume that each file will waste half a cluster on average, in slack space. If the cluster size is 2K, then the average file will waste 1K of disk space, regardless of how big the file is.

For NTFS, it's possible to set a cluster to be a sector. By default, NTFS will use a cluster size of 4K for a disk that's over 2GB in size. That means, on average, each file will waste 2K of disk. So, if you want to work out how much slack space there is on your NTFS disk, find out the number of files there, and multiply by 2 to get the approximate amount of slack space in Kb.

Sure, you can set NTFS to use a smaller cluster size, but you're into a compromise situation then. As you shrink the cluster size, the Master File Table (MFT) gets larger, and fragmentation more likely. There's also more overhead in RAM usage.