From: Greg KH <gregkh@suse.de>
To: Bodo Eggert <7eggert@gmx.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Randy Dunlap <randy.dunlap@oracle.com>, Mark Lord <lkml@rtr.ca>,
Jens Axboe <axboe@kernel.dk>, Jeff Garzik <jgarzik@pobox.com>,
Tejun Heo <htejun@gmail.com>, Linus Torvalds <torvalds@osdl.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
IDE/ATA development list <linux-ide@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ?
Date: Wed, 26 Mar 2008 20:52:57 -0700 [thread overview]
Message-ID: <20080327035257.GB9566@suse.de> (raw)
In-Reply-To: <E1JeTq5-00018y-MO@be1.7eggert.dyndns.org>
On Wed, Mar 26, 2008 at 12:30:40PM +0100, Bodo Eggert wrote:
> Greg KH <gregkh@suse.de> wrote:
> > On Tue, Mar 25, 2008 at 04:05:32PM -0700, H. Peter Anvin wrote:
>
> >>> How does this have anything to do with boot times? Do you really have a
> >>> foolish shell script that iteratorates over every single disk in the
> >>> sysfs tree for every disk? What does it do that for?
> >>
> >> Any time you want to get the sysfs information for a filesystem which is
> >> already mounted, that's what you're forced to do.
> >>
> >>> I thought we were talking about 2TB disks here, with a proposed new
> >>> ioctl, not foolishness of boot scripts...
> >>
> >> I pointed out that having a way to map device numbers to sysfs directories
> >> would have the same effect, *and* would be usable for other purposes. I'd
> >> rather see that than a new ioctl, and another, and another...
> >
> > Again, a simple udev rule will give you that today if you really want
> > it...
>
> So e.g. lilo should depend on sysfs and *a*special*configuration* of udev,
> while the admin MUST NOT use mknod'ed device files nor manually create
> symlinks pointing to them, and not use relative path names?
> That's plain stupid.
If sysfs is stupid, then use an ioctl, have I objected to that?
> > And I think 'udevinfo' can be used to retrieve this information as well.
>
> $ udevinfo /dev/hda
> missing option
> $ udevinfo /dev/hda --help
> Usage: udevinfo OPTIONS
> --query=<type> query database for the specified value:
> name name of device node
> symlink pointing to node
> path sysfs device path
> env the device related imported environment
> all all values
>
> --path=<devpath> sysfs device path used for query or chain
> --name=<name> node or symlink name used for query
>
> --root prepend to query result or print udev_root
> --attribute-walk print all SYSFS_attributes along the device chain
> --export-db export the content of the udev database
> --help print this text
> $ udevinfo --name=/dev/hda
> missing option
> $ udevinfo --name=/dev/hda --query=all
> P: /block/hda
> N: hda
> S: disk/by-id/ata-Maxtor_2F040L0_F1748ZQE
> S: disk/by-path/pci-0000:00:0f.0-ide-0:0
> E: DEVTYPE=disk
> E: ID_TYPE=disk
> E: ID_MODEL=Maxtor_2F040L0
> E: ID_SERIAL=F1748ZQE
> E: ID_REVISION=VAM51JJ0
> E: ID_BUS=ata
> E: ID_PATH=pci-0000:00:0f.0-ide-0:0
>
>
> As you can see, it gives no major:minor information. But it is in the DB:
That should be easy to add, no one has ever asked for this information
from udevinfo before. If it's needed, it can be provided.
> $ cd /dev/.udev/db
> $ grep -l hda * 2>/dev/null
> \x2fblock\x2fhda
> \x2fblock\x2fhda\x2fhda1
> $ cat "\x2fblock\x2fhda"
> N:hda
> S:disk/by-id/ata-Maxtor_2F040L0_F1748ZQE
> S:disk/by-path/pci-0000:00:0f.0-ide-0:0
> M:3:0
> E:DEVTYPE=disk
> E:ID_TYPE=disk
> E:ID_MODEL=Maxtor_2F040L0
> E:ID_SERIAL=F1748ZQE
> E:ID_REVISION=VAM51JJ0
> E:ID_BUS=ata
> E:ID_PATH=pci-0000:00:0f.0-ide-0:0
>
> What a great tool - for making linux look bad.
Your constructive criticism is greatly appreciated, please continue.
next prev parent reply other threads:[~2008-03-27 3:52 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <abhxL-xC-7@gated-at.bofh.it>
[not found] ` <abhRd-1bf-15@gated-at.bofh.it>
[not found] ` <ablib-2zv-65@gated-at.bofh.it>
[not found] ` <abn0B-735-35@gated-at.bofh.it>
[not found] ` <abna7-7jK-3@gated-at.bofh.it>
[not found] ` <abo6b-11J-9@gated-at.bofh.it>
[not found] ` <aboSP-2Wf-29@gated-at.bofh.it>
[not found] ` <aboSP-2Wf-27@gated-at.bofh.it>
[not found] ` <abqrq-6eX-29@gated-at.bofh.it>
[not found] ` <abqrq-6eX-27@gated-at.bofh.it>
[not found] ` <abqKM-6Ka-13@gated-at.bofh.it>
2008-03-26 11:30 ` What to do about the 2TB limit on HDIO_GETGEO ? Bodo Eggert
[not found] ` <E1JeTq5-00018y-MO@be1.7eggert.dyndns.org>
2008-03-27 3:52 ` Greg KH [this message]
2008-03-27 4:57 ` H. Peter Anvin
2008-03-27 14:45 ` Mark Lord
2008-03-27 15:15 ` Greg KH
[not found] <47E875AD.1000901@rtr.ca>
2008-03-25 4:02 ` Mark Lord
2008-03-25 4:19 ` Andrew Morton
2008-03-25 5:13 ` H. Peter Anvin
2008-03-25 13:37 ` Mark Lord
2008-03-25 13:55 ` H. Peter Anvin
2008-03-25 17:37 ` Mark Lord
2008-03-25 19:25 ` Greg KH
2008-03-25 19:34 ` Randy Dunlap
2008-03-25 20:36 ` H. Peter Anvin
2008-03-25 21:20 ` Greg KH
2008-03-25 21:26 ` H. Peter Anvin
2008-03-25 23:00 ` Greg KH
2008-03-25 23:05 ` H. Peter Anvin
2008-03-25 23:22 ` Greg KH
2008-03-27 19:05 ` Matthew Wilcox
2008-03-26 0:34 ` Mark Lord
2008-03-26 0:54 ` Tejun Heo
2008-03-26 3:38 ` Greg KH
2008-03-26 4:24 ` Tejun Heo
2008-03-26 6:04 ` H. Peter Anvin
2008-03-27 19:29 ` Kay Sievers
2008-03-27 19:38 ` H. Peter Anvin
2008-04-11 23:25 ` Dan Williams
2008-04-15 7:18 ` Andrew Morton
2008-04-15 13:47 ` Mark Lord
2008-04-15 14:20 ` James Bottomley
2008-04-15 18:16 ` H. Peter Anvin
2008-04-15 23:43 ` Dan Williams
2008-03-27 18:51 ` Kay Sievers
2008-03-27 18:55 ` H. Peter Anvin
2008-03-27 19:03 ` Kay Sievers
2008-03-25 15:17 ` James Bottomley
2008-03-25 17:31 ` Mark Lord
2008-03-25 19:32 ` James Bottomley
2008-03-25 17:45 ` Greg Freemyer
2008-03-25 17:52 ` Randy Dunlap
2008-03-25 18:09 ` Matthew Wilcox
2008-03-26 9:58 ` Boaz Harrosh
2008-03-30 4:28 ` Matt Domsch
[not found] ` <alpine.LFD.1.00.0803242254020.2775@woody.linux-foundation.org>
2008-03-25 13:34 ` Mark Lord
2008-03-25 13:51 ` Greg Freemyer
2008-03-25 14:31 ` Ric Wheeler
2008-03-25 15:25 ` Andrew Paprocki
2008-03-25 15:34 ` Matthew Wilcox
2008-03-25 15:48 ` Ric Wheeler
2008-03-25 16:47 ` Theodore Tso
2008-03-25 20:51 ` Theodore Tso
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=20080327035257.GB9566@suse.de \
--to=gregkh@suse.de \
--cc=7eggert@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=hpa@zytor.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=randy.dunlap@oracle.com \
--cc=torvalds@osdl.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;
as well as URLs for NNTP newsgroup(s).