Konrad Rzeszutek wrote: > .. snip .. >>> Also, values with magic block counts, while there is no way to get the >>> blocksize with the same interface, are pretty weird. I think the >>> current "size" attribute is just a bug. >> Logical block size is fixed at 512 bytes. Offset and size are always >> represented in multiples of 512 bytes and only get converted to >> hardware block size in the lld. > > That interpretation is at odds with the work that Martin Peterson is > doing with the 4K support. In the e-mail titled: "Re: [PATCH 4 of 8] sd: > Physical block size and alignment support", > Message-ID:<yq1ab67b51p.fsf@xxxxxxxxxxxxxxxxxx> he says: > > " > Konrad> about what a 'logical block', and 'physical block' is > Konrad> vs. 'hardware sector' ? > > Well, another item on my todo list is to kill the notion of hardware > sector completely. The protocols have been referring to logical blocks > for ages. > > It hasn't been a big problem until now because logical block size has > been equal to the hardware sector size. That's no longer a valid > assumption. > " > > Are the ATA/SCSI/etc specs at odds with each other about this? Hardware specs aren't of concern here. The logical block concept is there simply to give 9 bit addressing advantage, nothing more, nothing less. If hardware's sector size doesn't match it, the lld should be mapping the sector addresses and sizes and cdrom and a few other drives have been doing that for ages. There's nothing new about devices with sectors larger than 512 bytes. Thanks. -- tejun -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
