From: Andries Brouwer <aebr@win.tue.nl>
To: Alastair Stevens <alastair@camlinux.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Small oddity of the week: 2.4.20-pre
Date: Sun, 13 Oct 2002 00:46:09 +0200 [thread overview]
Message-ID: <20021012224609.GA23046@win.tue.nl> (raw)
In-Reply-To: <1034447457.2688.74.camel@dolphin.entropy.net>
On Sat, Oct 12, 2002 at 07:30:57PM +0100, Alastair Stevens wrote:
> On Sat, 2002-10-12 at 19:00, Andries Brouwer wrote:
> > > ie - the first time, it gives me two repeated lines. This appears to be
> > > random. In a clean terminal, it'll sometimes give me only the one line
> > > on the first run, and then do two lines multiple times....
> >
> > Could it be that you have statistics garbage in /proc/partitions?
> > That will break fdisk.
>
> Well, I'm no expert, but it looks OK to me:
>
> 953 alastair@dolphin:~> cat /proc/partitions
> major minor #blocks name rio rmerge rsect ruse wio wmerge wsect
> wuse running use aveq
>
> 3 0 58633344 hda 413162 1219920 12595886 1973640 268105 574049
> 6745668 8302590 -2 36995689 21817577
> 3 1 7253316 hda1 8 24 64 110 0 0 0 0 0 110 110
Some vendors added statistics to /proc/partitions.
Laziness on their side. Since they patch the kernel anyway
it would have been very easy to make /proc/diskstatistics.
But vendors may do as they wish.
This breaks some software, but these same vendors patch their
versions of this software.
Then some misguided people came and wanted this in the official kernel.
Bad. It is bad enough that vendors add pollution, but that good kernel
developers want to do this is inexplicable to me.
It only causes trouble, and gains precisely nothing.
In this particular case there are two problems:
(i) the format was changed
(ii) the content has become dynamic
Many proc files like /proc/filesystems or /proc/partitions may change,
but not many times a second, and most likely not without the operator
being aware of it. This means that programs like mount and fdisk can
read these files [1]. But a /proc/partitions that contains statistics
will change many times a second, causing problems for programs that
try to read it one line at a time.
My conjecture is that you were bitten by the latter phenomenon.
Andries
[1] The correct use of mount is to give an explicit type.
The correct use of fdisk is to give an explicit device.
Nothing else is guaranteed.
Shorthand versions work with high probability. But with a
dynamic /proc/partitions they work with lower probability.
next prev parent reply other threads:[~2002-10-12 22:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-12 14:00 Small oddity of the week: 2.4.20-pre Alastair Stevens
[not found] ` <20021012171642.GA22969@win.tue.nl>
[not found] ` <1034443816.10850.70.camel@dolphin.entropy.net>
2002-10-12 18:00 ` Andries Brouwer
[not found] ` <1034447457.2688.74.camel@dolphin.entropy.net>
2002-10-12 22:46 ` Andries Brouwer [this message]
2002-10-22 10:20 ` Alan Cox
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=20021012224609.GA23046@win.tue.nl \
--to=aebr@win.tue.nl \
--cc=alastair@camlinux.co.uk \
--cc=linux-kernel@vger.kernel.org \
/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