On 07/24/2016 03:51 PM, Bart Van Assche wrote:

On 07/24/16 06:37, Bart Van Assche wrote:

quoted

On 07/24/16 00:10, Hannes Reinecke wrote:

quoted

On 07/24/2016 12:13 AM, Bart Van Assche wrote:

quoted

On 07/23/16 05:43, Hannes Reinecke wrote:

quoted

On 07/22/2016 10:45 PM, Martin K. Petersen wrote:

quoted

quoted

quoted

quoted

quoted

quoted

"Hannes" == Hannes Reinecke [off-list ref] 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.
Typically SMR drives have a fixed zone size, and more often than not the
size of the zones is identical.
So mkfs would benefit from knowing the fixed zone layout as it then can
arrange the filesystem structures to align to those zones.
At the same time it doesn't need to know the write pointer, so full zone
information is not required here.
And during normal operation ideally the zone information is handled
within the kernel, so again userspace doesn't necessarily need to
have access to the full zone information.

So I guess I'll redo this one to export a sysfs attribute 'zone_size'
(if the zones are of identical size), and make the full zone information
available via debugfs.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)