linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Per Förlin" <per.forlin@axis.com>
To: Richard Weinberger <richard@nod.at>, Steve deRosier <derosier@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Artem Bityutskiy" <dedekind1@gmail.com>
Subject: Re: [PATCH] UBI: Add volume read and write statistics
Date: Wed, 18 Jul 2018 20:17:51 +0000	[thread overview]
Message-ID: <1531945071019.9858@axis.com> (raw)
In-Reply-To: <1886978.5HXsB66B85@blindfold>

> ________________________________________
> From: Richard Weinberger <richard@nod.at>
> Sent: Tuesday, July 17, 2018 5:10 PM
> To: Steve deRosier
> Cc: Per Förlin; linux-mtd@lists.infradead.org; Artem Bityutskiy
> Subject: Re: [PATCH] UBI: Add volume read and write statistics
> 
> Am Dienstag, 17. Juli 2018, 17:06:12 CEST schrieb Steve deRosier:
> > > > While having a cup of coffee I thought more about this.
> > > > Actually both, MTD and UBI makes sense.
> > > > The most important issue is that you integrate it with the existing diskstats.
> > > > So instead of having our own interface feeding MTD/UBI stats into diskstats
> > > > would be nice. Did you look into that? I'm not sure how much work this would be.
> > > > That way users can use existing tools such as iostat...
> > > I actually started out looking for the information under diskstats,
> > > then I learned it's only for block devices. I took a quick glance at
> > > it before I went for the sys implementation instead. diskstats is
> > > separated from the MTD and UBI stuff and I don't know if one can make a
> > > connection to MTD/UBI somehow. I will take a closer look at this.
> >
> > Perhaps it was "only for block devices" because no one ever
> > implemented the necessary hooks in MTD or UBI?  I don't know the
> > history, nor the information you found, just making a stab in the
> > dark.
> >
> > If UBI and/or MTD can provide the statistics that diskstats needs in a
> > interpretation that makes sense, why not go that way?
> 
> Yeah, that's what I have in mind. Maybe we can easily teach diskstats
> about MTD.
Now I got the chance to look at this again. It's not as bad as I thought.
The diskstats simply takes the block class and iterate over all devices.
For each device statistics are printed out.
It should be possible to do the same for the MTD class and the UBI class.
So far I haven't tested anything just reading code.
Then it's a matter of taste. Is MTD and UBI stats welcome in genhd.c?

I will try to find time the coming days or so to make a prove of concept
implementation to get a better idea of how big the change would be.

  reply	other threads:[~2018-07-18 20:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 10:30 [PATCH] UBI: Add volume read and write statistics Per Forlin
2018-07-17 10:39 ` Richard Weinberger
2018-07-17 12:08   ` Per Förlin
2018-07-17 14:34     ` Richard Weinberger
2018-07-17 15:01       ` Per Förlin
2018-07-17 15:06         ` Steve deRosier
2018-07-17 15:10           ` Richard Weinberger
2018-07-18 20:17             ` Per Förlin [this message]
2018-07-19 10:18               ` Per Förlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1531945071019.9858@axis.com \
    --to=per.forlin@axis.com \
    --cc=dedekind1@gmail.com \
    --cc=derosier@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).