On Thu, Feb 05, 2015 at 07:46:32PM +0200, "Kai Mäkisara (Kolumbus)" wrote: > > On 5.2.2015, at 19.40, Laurence Oberman <loberman@xxxxxxxxxx> wrote: > > From: "Kai Mäkisara (Kolumbus)" <kai.makisara@xxxxxxxxxxx> > > I still think that the tape statistics should be exported like the statistics of “real” block devices, i.e., one sysfs file exporting on a single line the statistics that temporally belong together. James rejected this approach. I am leaving the decision about this code to him. I will neither ack nor nak this code. > > > > I missed the earlier conversations with James, I will go search for them. > > Do you mean add them so they are similar to the /proc/diskstats http://comments.gmane.org/gmane.linux.scsi/80497 On Fri, Feb 22 2013 James Bottomley wrote: >>>> I'm afraid we can't do it the way you're proposing. files in sysfs must >>>> conform to the one value per file rule (so we avoid the ABI nastiness >>>> that plagues /proc). You can create a stat directory with a bunch of >>>> files, but not a single file that gives all values. Documentation/filesystems/sysfs.txt does not agree: "Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type." There's also ample precedent for this: sysfs disk and partition stats, SELinux cache and hash table stats (which have a pretty yucky 2d int array with column headers and a name: val format respectively). There's also a bunch of multivariate name=value format stats files in the cgroups sysfs tree. > Not exactly. I mean the data exported in sysfs, for example: > > > cat /sys/block/sda/sda1/stat > 159740 9006 5941506 64461 124724 55907 12772208 3598677 0 299875 3663235 I'd prefer to consume tape stats in this format too; it follows the principle of least surprise since it's shared with every other IO stats source (including device-mapper statistics) and it simplifies handling the counters in user space. Regards, Bryn. -- 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
