2009-04-12 01:09:19

by Daniel Collins

[permalink] [raw]
Subject: 2.6.28 /proc/diskstats

Hi

Since 2.6.28, fd0 isn't visible in /proc/diskstats from boot, only after
access/mount. It is visible in /sys/block/ from boot, so there are no
issues detecting it. This may also affect other devices such as hda but
I haven't tested this yet, my test system and QEMU both only have
ram0-ram15 from boot. I have tested 2.6.30-rc1 and found the same
behavior. Is this a bug or a deliberate change?

Thanks


2009-04-12 01:53:59

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.28 /proc/diskstats

On Sun, 12 Apr 2009 02:00:08 +0100 Daniel Collins <[email protected]> wrote:

> Hi
>
> Since 2.6.28, fd0 isn't visible in /proc/diskstats from boot, only after
> access/mount. It is visible in /sys/block/ from boot, so there are no
> issues detecting it. This may also affect other devices such as hda but
> I haven't tested this yet, my test system and QEMU both only have
> ram0-ram15 from boot. I have tested 2.6.30-rc1 and found the same
> behavior. Is this a bug or a deliberate change?
>

Tejun touched it last :)

2009-04-12 18:51:20

by Daniel Collins

[permalink] [raw]
Subject: Re: 2.6.28 /proc/diskstats

Reposting since I don't think anyone will see it ~150 messages down,
sorry if this is the wrong way to draw attention to a bug.

Daniel Collins wrote:
> Hi
>
> Since 2.6.28, fd0 isn't visible in /proc/diskstats from boot, only
> after access/mount. It is visible in /sys/block/ from boot, so there
> are no issues detecting it. This may also affect other devices such as
> hda but I haven't tested this yet, my test system and QEMU both only
> have ram0-ram15 from boot. I have tested 2.6.30-rc1 and found the same
> behavior. Is this a bug or a deliberate change?
>
> Thanks

2009-04-13 01:21:37

by Daniel Collins

[permalink] [raw]
Subject: Re: 2.6.28 /proc/diskstats

I've stepped through the commits in linux-2.6, the first revision with
this behavior is 074a7aca7afa6f230104e8e65eba3420263714a5

Daniel Collins wrote:
> Hi
>
> Since 2.6.28, fd0 isn't visible in /proc/diskstats from boot, only
> after access/mount. It is visible in /sys/block/ from boot, so there
> are no issues detecting it. This may also affect other devices such as
> hda but I haven't tested this yet, my test system and QEMU both only
> have ram0-ram15 from boot. I have tested 2.6.30-rc1 and found the same
> behavior. Is this a bug or a deliberate change?
>
> Thanks

2009-04-13 06:14:25

by Sam Ravnborg

[permalink] [raw]
Subject: Re: 2.6.28 /proc/diskstats

On Mon, Apr 13, 2009 at 02:21:10AM +0100, Daniel Collins wrote:
> I've stepped through the commits in linux-2.6, the first revision with
> this behavior is 074a7aca7afa6f230104e8e65eba3420263714a5

It would be a good idea to:
1) mention the subject of said path as no-one remember all these
SHA-1 anyway (but include the SHA-1 for reference.
2) copy the author of said patch.

The relevant patch is: "block: move stats from disk to part0"

I have copied Tejun and JEns.

The rest of the mail kept for reference.

Sam


>
> Daniel Collins wrote:
> >Hi
> >
> >Since 2.6.28, fd0 isn't visible in /proc/diskstats from boot, only
> >after access/mount. It is visible in /sys/block/ from boot, so there
> >are no issues detecting it. This may also affect other devices such as
> >hda but I haven't tested this yet, my test system and QEMU both only
> >have ram0-ram15 from boot. I have tested 2.6.30-rc1 and found the same
> >behavior. Is this a bug or a deliberate change?
> >
> >Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2009-04-14 07:53:19

by Tejun Heo

[permalink] [raw]
Subject: Re: 2.6.28 /proc/diskstats

Daniel Collins wrote:
> Hi
>
> Since 2.6.28, fd0 isn't visible in /proc/diskstats from boot, only after
> access/mount. It is visible in /sys/block/ from boot, so there are no
> issues detecting it. This may also affect other devices such as hda but
> I haven't tested this yet, my test system and QEMU both only have
> ram0-ram15 from boot. I have tested 2.6.30-rc1 and found the same
> behavior. Is this a bug or a deliberate change?

Hmm... the reason why fd device is skipped before the first open is
because diskstats_show() skips zero sized devices and open is when the
floppy driver sets the capacity. I think the original code also
skipped zero sized device. It could be that the original code
triggered revalidation while the current one doesn't. I'll dig
deeper.

Thanks.

--
tejun

2009-04-14 08:59:52

by Tejun Heo

[permalink] [raw]
Subject: Re: 2.6.28 /proc/diskstats

/proc/diskstats used to show stats for all disks whether they're
zero-sized or not and their non-zero partitions. Commit
074a7aca7afa6f230104e8e65eba3420263714a5 accidentally changed the
behavior such that it doesn't print out zero sized disks. This patch
implements DISK_PITER_INCL_EMPTY_PART0 flag to partition iterator and
uses it in diskstats_show() such that empty part0 is shown in
/proc/diskstats.

Reported and bisectd by Dianel Collins.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Daniel Collins <[email protected]>
---
It was my bad. I missed that diskstats showed empty disks too. This
fixes the problem.

block/genhd.c | 12 ++++++++----
include/linux/genhd.h | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index a9ec910..1a4916e 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -98,7 +98,7 @@ void disk_part_iter_init(struct disk_part_iter *piter, struct gendisk *disk,

if (flags & DISK_PITER_REVERSE)
piter->idx = ptbl->len - 1;
- else if (flags & DISK_PITER_INCL_PART0)
+ else if (flags & (DISK_PITER_INCL_PART0 | DISK_PITER_INCL_EMPTY_PART0))
piter->idx = 0;
else
piter->idx = 1;
@@ -134,7 +134,8 @@ struct hd_struct *disk_part_iter_next(struct disk_part_iter *piter)
/* determine iteration parameters */
if (piter->flags & DISK_PITER_REVERSE) {
inc = -1;
- if (piter->flags & DISK_PITER_INCL_PART0)
+ if (piter->flags & (DISK_PITER_INCL_PART0 |
+ DISK_PITER_INCL_EMPTY_PART0))
end = -1;
else
end = 0;
@@ -150,7 +151,10 @@ struct hd_struct *disk_part_iter_next(struct disk_part_iter *piter)
part = rcu_dereference(ptbl->part[piter->idx]);
if (!part)
continue;
- if (!(piter->flags & DISK_PITER_INCL_EMPTY) && !part->nr_sects)
+ if (!part->nr_sects &&
+ !(piter->flags & DISK_PITER_INCL_EMPTY) &&
+ !(piter->flags & DISK_PITER_INCL_EMPTY_PART0 &&
+ piter->idx == 0))
continue;

get_device(part_to_dev(part));
@@ -1011,7 +1015,7 @@ static int diskstats_show(struct seq_file *seqf, void *v)
"\n\n");
*/

- disk_part_iter_init(&piter, gp, DISK_PITER_INCL_PART0);
+ disk_part_iter_init(&piter, gp, DISK_PITER_INCL_EMPTY_PART0);
while ((hd = disk_part_iter_next(&piter))) {
cpu = part_stat_lock();
part_round_stats(cpu, hd);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 634c530..a1a28ca 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -214,6 +214,7 @@ static inline void disk_put_part(struct hd_struct *part)
#define DISK_PITER_REVERSE (1 << 0) /* iterate in the reverse direction */
#define DISK_PITER_INCL_EMPTY (1 << 1) /* include 0-sized parts */
#define DISK_PITER_INCL_PART0 (1 << 2) /* include partition 0 */
+#define DISK_PITER_INCL_EMPTY_PART0 (1 << 3) /* include empty partition 0 */

struct disk_part_iter {
struct gendisk *disk;

2009-04-14 09:01:26

by Tejun Heo

[permalink] [raw]
Subject: [PATCH] block: include empty disks in /proc/diskstats

/proc/diskstats used to show stats for all disks whether they're
zero-sized or not and their non-zero partitions. Commit
074a7aca7afa6f230104e8e65eba3420263714a5 accidentally changed the
behavior such that it doesn't print out zero sized disks. This patch
implements DISK_PITER_INCL_EMPTY_PART0 flag to partition iterator and
uses it in diskstats_show() such that empty part0 is shown in
/proc/diskstats.

Reported and bisectd by Dianel Collins.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Daniel Collins <[email protected]>
---
It was my bad. I missed that diskstats showed empty disks too. This
fixes the problem.

(Oops, forgot to write SUBJECT, resending...)

block/genhd.c | 12 ++++++++----
include/linux/genhd.h | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index a9ec910..1a4916e 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -98,7 +98,7 @@ void disk_part_iter_init(struct disk_part_iter *piter, struct gendisk *disk,

if (flags & DISK_PITER_REVERSE)
piter->idx = ptbl->len - 1;
- else if (flags & DISK_PITER_INCL_PART0)
+ else if (flags & (DISK_PITER_INCL_PART0 | DISK_PITER_INCL_EMPTY_PART0))
piter->idx = 0;
else
piter->idx = 1;
@@ -134,7 +134,8 @@ struct hd_struct *disk_part_iter_next(struct disk_part_iter *piter)
/* determine iteration parameters */
if (piter->flags & DISK_PITER_REVERSE) {
inc = -1;
- if (piter->flags & DISK_PITER_INCL_PART0)
+ if (piter->flags & (DISK_PITER_INCL_PART0 |
+ DISK_PITER_INCL_EMPTY_PART0))
end = -1;
else
end = 0;
@@ -150,7 +151,10 @@ struct hd_struct *disk_part_iter_next(struct disk_part_iter *piter)
part = rcu_dereference(ptbl->part[piter->idx]);
if (!part)
continue;
- if (!(piter->flags & DISK_PITER_INCL_EMPTY) && !part->nr_sects)
+ if (!part->nr_sects &&
+ !(piter->flags & DISK_PITER_INCL_EMPTY) &&
+ !(piter->flags & DISK_PITER_INCL_EMPTY_PART0 &&
+ piter->idx == 0))
continue;

get_device(part_to_dev(part));
@@ -1011,7 +1015,7 @@ static int diskstats_show(struct seq_file *seqf, void *v)
"\n\n");
*/

- disk_part_iter_init(&piter, gp, DISK_PITER_INCL_PART0);
+ disk_part_iter_init(&piter, gp, DISK_PITER_INCL_EMPTY_PART0);
while ((hd = disk_part_iter_next(&piter))) {
cpu = part_stat_lock();
part_round_stats(cpu, hd);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 634c530..a1a28ca 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -214,6 +214,7 @@ static inline void disk_put_part(struct hd_struct *part)
#define DISK_PITER_REVERSE (1 << 0) /* iterate in the reverse direction */
#define DISK_PITER_INCL_EMPTY (1 << 1) /* include 0-sized parts */
#define DISK_PITER_INCL_PART0 (1 << 2) /* include partition 0 */
+#define DISK_PITER_INCL_EMPTY_PART0 (1 << 3) /* include empty partition 0 */

struct disk_part_iter {
struct gendisk *disk;

2009-04-21 21:55:14

by Chris Wright

[permalink] [raw]
Subject: Re: [stable] [PATCH] block: include empty disks in /proc/diskstats

* Tejun Heo ([email protected]) wrote:
> /proc/diskstats used to show stats for all disks whether they're
> zero-sized or not and their non-zero partitions. Commit
> 074a7aca7afa6f230104e8e65eba3420263714a5 accidentally changed the
> behavior such that it doesn't print out zero sized disks. This patch
> implements DISK_PITER_INCL_EMPTY_PART0 flag to partition iterator and
> uses it in diskstats_show() such that empty part0 is shown in
> /proc/diskstats.
>
> Reported and bisectd by Dianel Collins.
>
> Signed-off-by: Tejun Heo <[email protected]>
> Reported-by: Daniel Collins <[email protected]>

looks like this isn't upstream yet.

thanks,
-chris

2009-04-22 05:41:24

by Jens Axboe

[permalink] [raw]
Subject: Re: [stable] [PATCH] block: include empty disks in /proc/diskstats

On Tue, Apr 21 2009, Chris Wright wrote:
> * Tejun Heo ([email protected]) wrote:
> > /proc/diskstats used to show stats for all disks whether they're
> > zero-sized or not and their non-zero partitions. Commit
> > 074a7aca7afa6f230104e8e65eba3420263714a5 accidentally changed the
> > behavior such that it doesn't print out zero sized disks. This patch
> > implements DISK_PITER_INCL_EMPTY_PART0 flag to partition iterator and
> > uses it in diskstats_show() such that empty part0 is shown in
> > /proc/diskstats.
> >
> > Reported and bisectd by Dianel Collins.
> >
> > Signed-off-by: Tejun Heo <[email protected]>
> > Reported-by: Daniel Collins <[email protected]>
>
> looks like this isn't upstream yet.

It'll go upstream today or tomorrow.

--
Jens Axboe