On 07/24/2016 07:37 AM, Bart Van Assche wrote:
On 07/24/16 00:10, Hannes Reinecke wrote:
On 07/24/2016 12:13 AM, Bart Van Assche wrote:
On 07/23/16 05:43, Hannes Reinecke wrote:
On 07/22/2016 10:45 PM, Martin K. Petersen wrote:
"Hannes" == Hannes Reinecke <hare@xxxxxxx> writes:
Hannes> Add a sysfs queue attribute 'zoned' to display the zone layout
Hannes> for zoned devices.
Not quite one value per file :(
Yes.
But I wanted to display the zone layout in a concise way allowing
user-space programs to determine the zone layout without having to
issue a 'REPORT ZONES' command themselves.
I found it slightly pointless to add one sysfs entry per zone,
and at the same time a simple 'zone_size' attribute wouldn't cover all
possibilities.
However, as SMR drives seem to stabilise around having a fixed zone
size
(with a possible exemption of the last zone to cover left-overs)
I'd be fine a replace this with a single 'zone_size' attribute which
could be set to eg '-1' for drives which indeed would implement
variable
zone sizes.
It's not that hard to convert the information exported by
queue_zoned_show() from a single sysfs attribute into one directory per
zone. Doing so would make it much easier for scripts to parse that
information and would also avoid that the zone information has to be
truncated because not all of it fits into a single page.
But this is precisely what I've tried to avoid.
Creating one file or directory per zone would mean we'll end up with
rough 20k files/directories.
Which I found rather excessive.
Of course, it that is not a concern that I can easily convert it.
If there are 10K zones and since queue_zoned_show() is limited to one
page then only a very small fraction of the zone information will be
available through sysfs. I remember from your presentations that reading
the zone information is slow. Is 10K zones a typical value or a worst
case value?
Just kill the sysfs file, it's useless for many zones. Either have the
application use some library to provide the information, or use bsg and
similar to get it.
--
Jens Axboe
--
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
