2 Aug 2007 19:31
Re: vblade performance issues -- resolved.
kelsey hudson <khudson@...>
2007-08-02 17:31:33 GMT
2007-08-02 17:31:33 GMT
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/