Re: PROBLEM: kernel 2.4.20 option CONFIG_BLK_STATS breaks /proc/partitons so "mount" can't mount devices by UUID.

From: Andries Brouwer (aebr@win.tue.nl)
Date: Thu Dec 19 2002 - 06:51:23 EST


On Wed, Dec 18, 2002 at 01:31:44PM -0200, Marcelo Tosatti wrote:

> Could you please expand on the "sporadically" so we can inform the user in
> a better way when he should not use CONFIG_BLK_STATS ?

He should never use it.

We had extensive discussion a few months ago, and I gave you
these Bugzilla references. Maybe you were confused because this
CONFIG_BLK_STATS code also was buggy, but that is unrelated.

Older versions of mount, fdisk and also the lvmutils, fail
because they expect the original format.

Later versions of mount and fdisk - I don't know about lvmutils -
just parse the start of a line, and hence can cope with additional
stuff at the end of the line.

But there is something else. One of the problems with statistics
in /proc/partitions is that the file changes dynamically - some
statistic can go from 99 to 100 and take a position more. A program
reading it will get bad data if it reads a buffer and then the next,
and between the two reads the contents shifts.

So far two solutions have been proposed:
A user side one: Tell stdio to use a very large buffer, in the hope
that all will be read at once. (This is what RedHat does.)
And a kernel side one: Make sure the kernel generates constant
length output.

[But it is really ridiculous to put ugly hacks in lots of programs -
Why? In order to avoid changing a single filename in sar?
Break mount in order not to break sar?
I still hope you remove this garbage again.]

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:23 EST