On 07/24/2016 11:56 PM, Hannes Reinecke wrote:
On 07/24/2016 03:51 PM, Bart Van Assche wrote:
On 07/24/16 06:37, 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?
(replying to my own e-mail)
Something I should have asked before: is the zone information intended
for end users or rather for software developers? In the latter case,
have you considered to use debugfs instead of sysfs to export this
information? From Documentation/filesystems/debugfs.txt: "Unlike /proc,
which is only meant for information about a process, or sysfs, which has
strict one-value-per-file rules, debugfs has no rules at all."
I would be perfectly fine with exporting the zone information via debugfs.
But at the same time I would like to have a simple sysfs representation
for SMR drives which can be utilized by mkfs and friend.
Then provide a real interface, through a library. Don't expose tons of
zones through sysfs, and expect applications to parse that. That's silly.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
