Ed L. Cashin wrote:
>> Is there any way to make the default disk geometry take into account
>> this alignment issue? Having anything other than a multiple of
>> eight as the number of sectors per track will result in a
> When the aoe driver was in its infancy we set up the CHS stuff in the
> "right way" for very large disks, following the example of the IDE
> driver at the time.
The "right" way seems to be a bit "wrong" in this case :) Yes, setting
the SPT number to 32 will effectively (about) halve the theoretical
size limit of an exportable device, but I do believe the throughput
gain is *well* worth it.
> If you specify the geometry using
> fdisk, can you get the same benefit
> without modifying the aoe driver?
Yes and no. Yes, I can manually intervene and set the geometry by hand.
The point is, I shouldn't *have* to. This throws a monkey wrench into
any automated processes that takes the disk geometry at face value when
Case-in-point: I do automated OS installs over AoE devices in Xen.
There isn't a way for me to specify the disk geometry in, for instance,
a kickstart file.
What we can do to avoid the page alignment problem is to be
smart about calculating the geometry. Instead of always reporting a
blanket 255 heads, 63 SPT to get the most of the 65536 cylinders, we
can report 256 heads (0 heads makes no sense), and the best multiple of
8 SPT that will fit (about) evenly into the exported device. I chose 32
SPT because it's a good, round number; conceivably we could use 56 SPT
if the math lines up (this way you're only losing 12.5% of the maximum
cylinder size). If the exported device would exceed the maximum number
of cylinders at the maximum cylinder size, then we should export the
geometry mis-aligned to compensate, but absolutely print a warning to
At this point it's all about cylinder size. Yes, bigger is better, but
the performance on streamed writes (and reads, to a certain extent due
to excess seeks) is *always* going to be bad if the pages on the target
don't align with the pages on the initiator. My personal observation is
that this results in about a 1200% speed-up on sustained writes; we
can't simply discount this as optional.
Besides, to what portion of the typical users do you think this will
even occur? Sure, we can document it ad nauseam, but in the end I think
most users won't understand the need to change the disk geometry, nor
will they be apt to do so even if presented with the reasons why. It's
an advanced concept that a *lot* of people have a hard time
I apologize if this may come off a bit strong or rude; this is not my
intent. I just want to see AoE become a real competitor with things
like iSCSI and Fibre Channel. With fundamental performance problems
like this I fear it won't happen.
If it helps, I can start on a patch to the AoE driver so that it
reports geometry based on the size of the device or file exported and
defaults to the largest number of sectors per track possible with the
least amount of wasted space at the end of the media.