[lkml]   [2010]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCHSET] libata: implement ->set_capacity()
    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)?


     \ /
      Last update: 2010-05-13 18:09    [W:0.042 / U:3.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site