On Thu, 2010-05-13 at 17:56 +0200, Tejun Heo wrote: > Hello, Jens, James, Jeff, > > This patchset implements ->set_capacity() in libata so that HPA can be > unlocked on demand. > > 0001-block-restart-partition-scan-after-resizing-a-device.patch > 0002-SCSI-implement-sd_set_capacity.patch > 0003-libata-use-the-enlarged-capacity-after-late-HPA-unlo.patch > 0004-libata-implement-on-demand-HPA-unlocking.patch > > 0001 makes partition scan code to restart after ->set_capacity(). > This makes sure that partitions which start beyond the HPA limit are > discovered. > > 0002 implements ->set_capacity() in sd. > > 0003 makes libata accept device capacity larger than the initial one. > > 0004 implements ->set_capacity() in libata which asks libata EH to > unlock HPA, waits and returns the new capacity. > > Ben Hutchings suggeseted implementing ->set_capacity() in libata and > also reported the bug in the current partition scan code where it > fails to discover partitions which start beyond the HPA limit. > > Unlocking HPA on-demand seems to be the safest default way to deal > with HPA. Leaving HPA alone by default could fail to detect or > truncate existing partitions while unlocking by default make it more > prone to obscure data corruptions when combined with BIOSes beliving > that they exclusively own the area beyond HPA limit. > > 0001 should be routed through the block tree. 0002 should go through > SCSI but given the dependency and that libata is the only user, it > would probably much easier to route it through libata-dev#upstream > together with 0003 and 0004. I'm not sure this is such a good interface ... it sounds very error prone for what is effectively a binary lock/unlock. Instead of just saying unlock the HPA and show me the new capacity (with a rescan), you have to echo the right number of sectors to the set_capacity variable. Isn't a hpa_unlock libata specific attribute better (you could even call BLKRRPART from the user context of the write)? James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
