LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andries Brouwer <aebr@win.tue.nl>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Linus Torvalds <torvalds@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: rfc: test whether a device has a partition table
Date: Thu, 25 Sep 2003 14:14:42 +0200 [thread overview]
Message-ID: <20030925121442.GC21508@win.tue.nl> (raw)
In-Reply-To: <20030925000503.GC7665@parcelfarce.linux.theplanet.co.uk>
On Thu, Sep 25, 2003 at 01:05:03AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> If there is no partition table at all and in fact they have a filesystem
> on the entire disk - let them use *entire* *disk*. You can very well
> read /dev/sd<letter>, mount it, whatever. Here I do have a SCSI disk
> that is not partitioned at all. And guess what? It works with no extra
> efforts needed:
>
> SCSI device sda: 35916548 512-byte hdwr sectors (18389 MB)
> sda: unknown partition table
>
> al@satch:~/kernel/2.5$ mount | grep sda
> /dev/sda on /mnt/sda type ext2 (rw)
>
> Note that usb-storage looks like a SCSI host for the rest of kernel, so that's
> exactly the same situation - device that is expected to be partitioned but in
> reality isn't.
>
> So what precisely are you trying to fix?
You forget two things.
First, if the kernel comes up with a bogus partition table, this
will confuse users (and user space) greatly. It is not harmless,
even though you would know how to survive.
Second, if the kernel reads random stuff from flash media that may yield
I/O errors. Such media do often not have blocks at a fixed place, but
have at the start a table that says where on the media a given block lives.
Blocks that have never been written do not occur in the table, and attempts
to read them give an I/O error. (And our famous SCSI error handling may
want to retry a few times, reset the device and retry, reset the bus
and retry .. I have seen boot times of a quarter of an hour because
the kernel was busy retrying SmartMedia accesses.)
In short - we should not read random blocks from a disk on flash media.
Andries
next prev parent reply other threads:[~2003-09-25 12:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-24 20:29 Andries.Brouwer
2003-09-24 21:54 ` Linus Torvalds
2003-09-24 23:50 ` Andries Brouwer
2003-09-25 0:05 ` viro
2003-09-25 12:14 ` Andries Brouwer [this message]
2003-09-25 0:18 ` Linus Torvalds
2003-09-25 6:53 ` Xavier Bestel
2003-09-25 10:57 ` Andries Brouwer
2003-09-25 4:47 ` Linus Torvalds
2003-09-25 4:56 ` Linus Torvalds
2003-09-25 11:42 ` Andries Brouwer
2003-10-05 9:00 ` Meelis Roos
2003-09-25 0:42 ` Douglas Gilbert
2003-09-25 1:00 ` viro
2003-09-25 1:27 ` Douglas Gilbert
2004-05-22 11:18 Uwe Bonnes
2004-05-22 12:37 ` John Bradford
2004-05-22 12:56 ` Andries Brouwer
2004-05-22 15:14 ` Uwe Bonnes
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=20030925121442.GC21508@win.tue.nl \
--to=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
--subject='Re: rfc: test whether a device has a partition table' \
/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
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).