libata: implement ->set_capacity()
in [Kernel]
|
Prev: [PATCH 1/1] staging: hv: Fix error checking in channel.c
Next: ftrace syscalls, PowerPC: Fixes and PowerPC raw syscall tracepoint implementation
From: James Bottomley on 13 May 2010 12:10 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 13 May 2010 12:30 Hello, On 05/13/2010 06:06 PM, James Bottomley wrote: > I'm not sure this is such a good interface ... it sounds very error > prone for what is effectively a binary lock/unlock. Well, the original block interface was like that. It has been used as binary switch tho. The requested capacity is always ~0ULL and return value smaller than the current capacity is ignored. I'm all for dropping the capacity parameter and the return value from ->set_capacity() so that it just unlocks native capacity and directly sets the new capacity. Jens? > 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)? Hmmm... I lost you. What are you talking about? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 13 May 2010 12:40 On Thu, 2010-05-13 at 18:22 +0200, Tejun Heo wrote: > > 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)? > > Hmmm... I lost you. What are you talking about? Instead of making this a block sysfs attribute, since HPA is SATA only, why not make it a libata attribute for the disk? That way on unlock, you can unlock the HPA and then trigger a partition rescan of the block device (BLKRRPART) ... this is an ioctl, so you need user context, but you have it if you do it from the sysfs write routine. This looks to be a lot simpler than threading it up through SCSI and block. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 13 May 2010 13:00 Hello, On 05/13/2010 06:38 PM, James Bottomley wrote: > Instead of making this a block sysfs attribute, since HPA is SATA only, > why not make it a libata attribute for the disk? > > That way on unlock, you can unlock the HPA and then trigger a partition > rescan of the block device (BLKRRPART) ... this is an ioctl, so you need > user context, but you have it if you do it from the sysfs write routine. > This looks to be a lot simpler than threading it up through SCSI and > block. This doesn't have anything to do with sysfs. It's called from block partition scan code when it detects a partition extends beyond the end of the device. No user intervention at all and the mechanism has been there for quite some years and possibly predates sysfs. Am I being really slow or are you looking at something else? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 13 May 2010 13:10
On Thu, 13 May 2010 11:38:07 -0500 James Bottomley <James.Bottomley(a)suse.de> wrote: > On Thu, 2010-05-13 at 18:22 +0200, Tejun Heo wrote: > > > 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)? > > > > Hmmm... I lost you. What are you talking about? > > Instead of making this a block sysfs attribute, since HPA is SATA only, > why not make it a libata attribute for the disk? HPA is both PATA and SATA (and USB SCSI pass through ATA over SCSI etc with some of the more functional USB/ATA bridges. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |