On Tue, Jul 06 2010 at 9:39pm -0400, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes: > > >> That is 0x7fffff (over 8 million) blocks (4 GB) being unmapped in one > >> operation! That may exceed the "maximum unmap lba count" field in the > >> Block Limits VPD page. The latest SBC draft (sbc3r22.pdf) says that > >> field applies to the SCSI UNMAP command and does not mention the > >> WRITE SAME (16) command but that is probably an oversight. > > Maximum Unmap LBA Count > 0 (in combination with the descriptor count) > are what indicate that the device server supports UNMAP. > > You could argue, then, that a Maximum Unmap LBA Count > 0 but a Maximum > Unmap Descriptor Count of 0 would provide means to indicate the maximum > range for WRITE SAME. But the T10 people I have talked to all agree > that the LBA count for WRITE SAME is gated by the command's LBA count > and nothing else. So no special casing for when the UNMAP bit is set. > I.e. the max for WRITE SAME(16) is 32-bits times logical_block_size. Ah, yes completely missed that fact that we're talking WRITE SAME(16) yet I was looking at UNMAP limits. > > Mike> # cat /sys/block/sda/queue/discard_granularity > Mike> 512 > Mike> # cat /sys/block/sda/queue/discard_max_bytes > Mike> 4294966784 > > Mike> I'll look to understand why 'discard_max_bytes' is so large for > Mike> this LUN despite the standard Block limits VPD page not reflecting > Mike> this. > > discard_max_bytes is 0xFFFFFFFF for WRITE SAME(16). Seems discard_max_bytes = 0x7fffff * 512 = 4294966784 So mkfs.ext4's BLKDISCARD ioctl first issues a discard of discard_max_bytes (via blkdev_issue_discard's loop) and it fails. Question becomes: why did the request fail if the LUN supports WRITE SAME(16) and its max is 0xFFFFFFFF? Likely a question for the vendor but I'd first like to make sure it is reasonable to expect this command to succeed. Thanks, Mike -- 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
