Our new fileserver setup requires that all of the LUNs exported by the backend SAN be exactly the same size, down to the block, so that we can always mirror two arbitrary LUNs together. We wanted our basic LUN size to be around 200 to 250 GB, but that's a large range of possible sizes, and it still left us to pick a sensible exact block size.

Our first approach was to take our 750 GB Seagate SATA disks and divide them up into three equal slices. While temptingly simple, this is dangerous, because different 750 GB drives from different vendors are slightly different sizes, and for that matter the 1 TB and 1.5 TB drives are not necessarily going to be exactly 4/3rds or 2 times larger than our current 750 GB drives. We thought about compensating for this by leaving some amount of spare space as a margin for error, but that only changed the problem to how much spare space we should leave.

(At this point it becomes important to remember that drive vendors quota sizes in 'decimal' gigabytes, where one dKB is 1,000 bytes, one dMB is 1,000 dKB, one dGB is 1,000 dMB, and so on.)

For our second attempt we started from first, well, assumptions (I cannot call them principles). The one thing we can be relatively confident of is that disk vendors will not be able to sell a '750 GB' drive that has less than 750 (decimal) GB of capacity, and similarly for 1 TB and 1.5 TB drives (if nothing else, it sails awfully close to misleading advertising). So we can achieve our goals by making our slices be 250 (decimal) GB or slightly under that.

This gave us a starting figure in (real) KB; however, it ignored any overhead from Linux partitioning and had no margin for error. So we rounded it down slightly; specifically, we rounded it down so that it was evenly divisible by 32 MB. We chose 32 MB so that we could create LVM volumes that were exactly this size and thus could use LVM on our SAN backends if we some day needed to.

(LVM volumes must be exact multiples of the LVM physical extent size, which has to be a power of two and wants to be large for efficiency. 16 MB is the default.)

(To save you the math: 250 decimal GB is 244140625 KB, and we rounded down to 244121600 KB. This 'wastes' 18.5 MB per LUN, plus however much a disk is larger than exactly 750 decimal GB, 1 decimal TB, and so on. The disks we've looked at so far are not substantially larger than advertised, so this is basically a trivial amount of space.)

Trying to create partitions that were exactly this size is where I got to find out about the effects of various fdisk options.