fdisk: slices with exact number of sectors not possible?

Hi,
I try to slice a SATA hard disk (BIOS: Block Mode 64 Sectors) into four parts with same numbers of sectors. The problem is to create all four slices with equal numbers of sectors.

FDISK always changes the entered size so I never get what I entered.

After having created the first slice I found no way to create the next slice with the exact same size (number of sectors) as the first one.
When creating the third slice you can find a size by trial and error that is not changed by FDISK ending up with the last three slices in equal size, but never get matched with the first slice.

BTW adding or subtracting 63 boot sectors when entering the size does not help, as the FDISK changes the entered size up to thousands of sectors.

Any ideas how to get it done?
 
I think you should be able to do this from Linux fdisk. I never use BSD fdisk, I partition (slice) in Linux and then I install and disklabel from the BSD installer.
 
I'm still ambitious to do it with FreeBSD, looking for a way to adjust the size of slices without reinstalling Windows or looking into penguins I don't know.
 
Thanks for the hint, but for time being I need to stay with MBR partitions. Still looking for an editing tool for (re)sizing UFS MBR.

I'd like to know, why FDISK is not just taking the input and doing what I want it to. Instead it is altering the wanted size to something else. If this is a wanted optimizing behaviour/ feature I'd like to know it.
 
Don't bore so hard. It's some hardware limitation. Your hdd not realy have 16 headers and 64 sectors on cylinder. This number many much. And fdisk always align slice size to appropriate value based on real hdd configuration.
 
pablo said:
Don't bore so hard. It's some hardware limitation. Your hdd not realy have 16 headers and 64 sectors on cylinder. This number many much. And fdisk always align slice size to appropriate value based on real hdd configuration.

Sorry, but I don't get you. What do you want me to know?
Please see screencopy of FDISK running.

1. partition has size of 104984712

I want 2., 3. and 4. partition of exactly same size.

Now creating 2nd partition I enter 104984712 and FDISK alters to 104984775.

Starting with 104984775 for the 1. partition results in 104984712.

These size of 104984775 I found through iteration which FDISK does not alter. If you enter i.e. 100000000 FDISK alters heavily.
 
The first 63 sectors are reserved, and already taken.For partitioning you always have total_nr_of_sectors - 63 available for partitioning.

Because the partitions have to be aligned on a cylinder boundary (heads x sectors = 255 x 63 = 16065 sectors), the first partition will always have 63 sectors less then the others. The others can have about equal sizes.

Your empirically derived size of104,984,775 is a multiple of 16065 (255*63) sectors
Code:
$ echo "scale=2 ; 104984775/16065" | bc
6535.00
You actually can do better. The number of sectors is
Code:
$ echo 30401*255*63 | bc
488392065
This is 30401 cylinders of 16065 sectors. Dividing 30401 cylinders by 4
Code:
$ echo "scale=2 ; 30401/4" | bc 
7600.25
So you actually could have 4 partitions of
Code:
$ echo 7600*16065 | bc 
122094000
122,094,000 sectors. The first partition would be 63 sectors smaller.The second and third partition would be 122,094,000 sectors while the last could use the extra cylinder (4 x 0.25 = 1)
Code:
$ first=$(echo 122094000-63 | bc )
$ echo $first
122093937

$ second=122094000
$ third=$second

$ fourth=$(echo 122094000+16065 | bc)
$ echo $fourth
122110065

# ---- total used for partitioning
$ echo "$first+$second+$third+$fourth" | bc
488392002

# add in the first 63 sectors reserved for MBR etc
$ echo "$first+$second+$third+$fourth+63" | bc
488392065
This last number exactly matches the product of 30401 x 255 x 63.
Code:
$ echo 30401*255*63 | bc                       
488392065
 
Thank you for the calculations. Nice way to use "bc".

The cylinder-boundary problem is understood. For compatibility it is better to calculate with cylinders when using FDISK. FDISK looks outdated to me, but I still have to use MBR. Future points to GPART.

I'll try to make the first slice a swap (2*RAM). Creating the next three slices (without swaps) with equal size is no more a problem to me.
I hope that my idea with a swap-slice works out.
 
Back
Top