Limit the number of REPORT_ZONES entries allocated in the kernel.

[markj]

Summary

The DIOCGETZONE ioctl can be used to fetch the zone list of an SMR
drive, and the caller specifies the number of entries it wants to fetch.
Clamp the caller's request to a sane limit so that a user cannot attempt
large allocations. Callers already need to invoke the ioctl multiple
times to fetch the full list in general, so there's no harm in limiting
the number of entries returned.

Test Plan

None, I don't have any SMR drives. Would either of you be willing to
test zonectl -c rz with this patch applied?

[asomers]

This change looks good. However, zonectl(8) currently hard-codes the entries_allocated field and doesn't check for a short return. If the kernel truncates the zone list, the user will have no obvious way of knowing. I think zonectl(8) should be modified to either loop until all zones have been reported, or at least tell the user that not all zones were reported.

[markj]

In D19249#411871, @asomers wrote:

This change looks good. However, zonectl(8) currently hard-codes the entries_allocated field and doesn't check for a short return. If the kernel truncates the zone list, the user will have no obvious way of knowing. I think zonectl(8) should be modified to either loop until all zones have been reported, or at least tell the user that not all zones were reported.

Sorry, I don't quite follow. The number of entries returned is in entries_filled, which zonectl does check, and the kernel ensures that entries_filled <= entries_allocated. What am I missing?

[ken]

In D19249#411871, @asomers wrote:

This change looks good. However, zonectl(8) currently hard-codes the entries_allocated field and doesn't check for a short return. If the kernel truncates the zone list, the user will have no obvious way of knowing. I think zonectl(8) should be modified to either loop until all zones have been reported, or at least tell the user that not all zones were reported.

zonectl does ask for entries_allocated, but it will only print the number of zone descriptors that were returned. It will then ask for the next batch of zone descriptors starting at the next lba offset.

e.g., my test Host Aware drive is 8TB and has 29809 zones. zonectl allocates 16384 entries, and MAXPHYS is 1MB. So it will take at least two passes to print out all the zones. If MAXPHYS were lower, it would take more passes, since the da(4) driver will limit it.

[asomers]

Sorry, I missed that. I was searching for the wrong thing. In that, case, this change LGTM. I can't test it, though.

[ken]

I tested this out with a Seagate 8TB host aware drive:

{sm4u-1-mgmt:/usr/home/kenm:!:0} camcontrol inquiry da14 -v
pass14: <ATA ST8000AS0022-1WL ZN03> Fixed Direct Access SPC-4 SCSI device
pass14: Serial Number Z84003SK
pass14: 600.000MB/s transfers, Command Queueing Enabled

It produces the same results as before with zonectl -c rz

[markj]

In D19249#411899, @ken wrote:

I tested this out with a Seagate 8TB host aware drive:

{sm4u-1-mgmt:/usr/home/kenm:!:0} camcontrol inquiry da14 -v
pass14: <ATA ST8000AS0022-1WL ZN03> Fixed Direct Access SPC-4 SCSI device
pass14: Serial Number Z84003SK
pass14: 600.000MB/s transfers, Command Queueing Enabled

It produces the same results as before with zonectl -c rz

Thanks!