From: Jeff Garzik <jgarzik@pobox.com>
To: Thomas Horsten <thomas@horsten.com>
Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: ATARAID userspace configuration tool
Date: Tue, 10 Feb 2004 12:38:00 -0500 [thread overview]
Message-ID: <402916F8.8050008@pobox.com> (raw)
In-Reply-To: <Pine.LNX.4.40.0402101405190.25784-100000@jehova.dsm.dk>
Thomas Horsten wrote:
> - Is there a "recommended" way to enumerate all block devices (not
> partitions) from userside? Since this is ATA RAID, I could of course just
> read the ideX majors from /proc/devices and try all the minors, but I
> would prefer to get a list of all detected block devices in a portable
> way.
sysfs, definitely.
> - After I have used the DM (and possible MD for some RAID types) to map
> the ataraid devices, is there a way to remove the partitions from the
> underlying disks from the kernel? This was my main reason for wanting to
> do kernel-level autodetection of these arrays, so I could prevent add_disk
> from being called and analysing the partition table (on these BIOS RAIDs,
> in striped mode the first disk contains the partition table for the entire
> array in sector 0, and if the user (or a script) tries to mount the
> partitions (or even read the extended partition table) it may try to read
> after the end of the disk and will in any case use wrong sector numbers -
> leading to possible disk corruption.
You have control of what happens to the devices. If you don't want them
probed for partitions, they won't be..
> On top of this it would be useful to make the underlying devices
> inaccessible after the mapped device is created (to prevent people from
> doing things like fdisk /dev/hda, when what they really wanted was
> something like fdisk /dev/ataraid/disc).
This would be something to talk with the md maintainer about, I think.
I'm not sure we want to do this, since the user may have a valid reason
to access the underlying disk.
Jeff
next prev parent reply other threads:[~2004-02-10 17:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-10 14:18 ATARAID userspace configuration tool Thomas Horsten
2004-02-10 14:18 ` Thomas Horsten
2004-02-10 14:51 ` Matt Domsch
2004-02-10 14:58 ` Christophe Saout
2004-02-10 18:26 ` Kevin P. Fleming
2004-02-10 18:26 ` Kevin P. Fleming
2004-02-10 19:18 ` Christophe Saout
2004-02-10 19:24 ` Kevin P. Fleming
2004-02-10 19:24 ` Kevin P. Fleming
2004-02-11 1:35 ` Greg KH
2004-02-11 1:45 ` Kevin P. Fleming
2004-02-11 1:45 ` Kevin P. Fleming
2004-02-11 11:34 ` Christophe Saout
2004-02-11 14:18 ` Kevin P. Fleming
2004-02-11 14:18 ` Kevin P. Fleming
2004-02-11 19:48 ` Christophe Saout
2004-02-10 17:38 ` Jeff Garzik [this message]
2004-02-10 17:47 ` Thomas Horsten
2004-02-10 17:47 ` Thomas Horsten
2004-02-10 18:44 ` Jeff Garzik
2004-02-10 22:41 ` Neil Brown
2004-02-10 22:41 ` Neil Brown
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=402916F8.8050008@pobox.com \
--to=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=thomas@horsten.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.