Page MenuHomeFreeBSD

Limit the number of REPORT_ZONES entries allocated in the kernel.
ClosedPublic

Authored by markj on Feb 19 2019, 7:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Mar 20, 1:23 AM
Unknown Object (File)
Feb 19 2024, 2:36 AM
Unknown Object (File)
Jan 20 2024, 7:55 AM
Unknown Object (File)
Jan 1 2024, 6:51 PM
Unknown Object (File)
Dec 20 2023, 6:18 AM
Unknown Object (File)
Nov 17 2023, 4:04 PM
Unknown Object (File)
Nov 15 2023, 8:28 PM
Unknown Object (File)
Nov 15 2023, 8:22 PM
Subscribers

Details

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?

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj added reviewers: ken, 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.

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?

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.

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

This revision is now accepted and ready to land.Feb 19 2019, 7:40 PM

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

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!

This revision was automatically updated to reflect the committed changes.