On Fri, 20 Mar 2015, Ewan Milne wrote: > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote: > > This patch provides a sysfs interface allowing users to override the > > capacity of a SCSI disk. This will help in situations where a buggy > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only > > the low 32 bits of the capacity in its READ CAPACITY(10) reply. For > > an example, see this thread: > > > > http://marc.info/?l=linux-scsi&m=140908235510961&w=2 > > > > The interface is awkward because it requires the user to tell the > > system to re-read the disk's partition table afterward, but at least > > it provides a way to handle deficient hardware. > > I think that it is confusing that writing into the capacity_override > sysfs node does not get immediately reflected in the gendisk structure. > Would it hurt to call sd_revalidate_disk() after the value is changed > in capacity_override_store()?
It wouldn't hurt, but it wouldn't help much either. sd_revalidate_disk() might cause the new size to show up in the gendisk structure, but it would not cause the partition table to be parsed again. That's the real reason for doing this -- when a drive seems to have fewer blocks than it really does, partitions that extend beyond the "end" of the drive are rejected. > The thing is, if someone overrides the capacity but does not do anything > right away to revalidate the disk, it could change at some arbitrary > time in the future when the revalidation happens for some other reason. That's why the documentation says that users must force the system to re-read the partition table after writing the sysfs attribute. In my tests, doing that caused a revalidation. Are you saying that could have been a coincidence? It's possible -- I don't understand the design of the block layer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
