Re: vblade performance issues -- resolved.

Ed L. Cashin wrote:
> It's an interesting idea.
> 
> I wonder whether we can be sure that users who have disks partitioned
> with an earlier driver would not run into problems if the driver was
> changed in this way.

We *should* be fine. The kernel will first look at the partition table 
on the disk and convert LBA numbers back to CHS numbers to determine the 
C/H/S count; if this isn't available or it doesn't make sense, it'll 
perform an inquiry to get the physical geometry of the disk. fdisk et al 
do the same thing.

 From what I understand of the LBA partition table, all the CHS 
partition start and end locations are set to 0xFF, and only the 32-bit 
LBA numbers are actually used to describe the location of a partition. 
Since the LBA number can be converted back to a CHS number we should be 
OK. Linux never uses CHS numbers to describe partitions anyways, even in 
the case where the disk is less than 1024 cylinders long.

The *only* thing I can see even remotely being a problem are older 
virtual disks that may have been partitioned with DOS FDISK, because DOS 
FDISK (and the DOS MBR) is brain-dead and still uses the CHS method to 
assign partitions. If it relies on the geometry reported from the disk, 
the partition table will be marked invalid by the boot loader code in 
the first 446 bytes of the disk. This will likely only be a problem for 
people who are running DOS virtual machines in e.g. vmware and Xen. I 
won't say that nobody is doing this (as there may very well be), but I 
have to imagine this number of users being quite low.

After a bit of thinking, we should be able to simply change the reported 
geometry to 256 heads and 56 sectors per track (or some other 
appropriate multiple of 8) in *all* cases without too much a problem ... 
If Linux never looks at the CHS numbers except for LBA translation, then 
it should be a non-issue. Unfortunately, I don't have a 500-2048 GByte 
array to test these modifications with to see if it really does have an 
impact on the maximum size of an export.

I do currently have a *ton* of disks exported to VMs via AoE, though. 
I'd be more than happy to test this with them once I have the driver 
appropriately modified.

I'll send a patch when I'm done.

Cheers,
-Kelsey

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/