On Mon, Dec 21, 2009 at 1:59 PM, Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> wrote: ... >> > Just a wild idea but maybe the current block infrastructure for handling >> > ATA HPA (see commit db429e9 and e957b60 one) can be used to automatically >> > detect and workaround the issue? >> >> Are you referring to this change? >> + libata.ignore_hpa= [LIBATA] Ignore HPA limit >> + libata.ignore_hpa=0 keep BIOS limits (default) >> + libata.ignore_hpa=1 ignore limits, using full disk > > Nah. > >> My git-foo isn't very good...what command will display the two changes >> you refer to above? > > git log -p --color db429e9^1..e957b60 Perfect! > We should be able to detect working SD reader/card combination in sd > driver's ->set_capacity method implementation (i.e. by issuing read > request for the last partitioned sector outside of the reported device > capacity) during the initial partition table scan and at the same time > adjust the device capacity used by the kernel if necessary. Yup - I think you are right. > New/empty cards would still need to be 'force partitioned' first using > fdisk (or sfdisk if fdisk doesn't allow such operation) but after it's > done the partition rescan on fdisk's exit will recognize new device's > capacity automatically.. > >> about b0rked HW, the user (or udev maybe?) can workaround this issue. >> Given how simple the patch, I don't see any reason to reject it. > > Simple to write or simple to maintain? ;) Write of course. :) And in retrospect, even that statement is wrong since nothing in the storage stack is as simple as it looks. > To be honest the patch looks like a gross and dangerous hack.. Agreed. I expect there will always be some devices that will get the partition/device size wrong and it would be expedient use this hack to work around "non-compliant" devices. Clemens already proved it works for him (even though it's not quite right). > Firstly block layer needs to be properly informed about capacity changes > (set_capacity() + request for partition rescan which the patch doesn't do) > and secondly fixing the problem at the sysfs block/partition layer seems > to be a layering violation (i.e. it also allows partition size changes). It's the exported interface to user space. So while it's not implemented correctly to deal with resizing (which I didn't realize, Clemens will have to fix that), I don't consider it a layering violation if there are APIs this code can call to notify of the partition size change. thanks! grant > > -- > Bartlomiej Zolnierkiewicz > -- > 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 > -- 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
