From: Joel Becker <Joel.Becker@oracle.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: bert hubert <ahu@ds9a.nl>, Greg KH <greg@kroah.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andries.Brouwer@cwi.nl,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Wim Coekaerts <Wim.Coekaerts@oracle.com>
Subject: Re: 64-bit kdev_t - just for playing
Date: Mon, 31 Mar 2003 09:24:04 -0800 [thread overview]
Message-ID: <20030331172403.GM32000@ca-server1.us.oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0303311039190.5042-100000@serv>
On Mon, Mar 31, 2003 at 10:52:53AM +0200, Roman Zippel wrote:
> > Can you envision solutions based on 16 bit kdev_t infrastructure?
>
> I know that 16bit is getting small (but with dynamic assignment even
> that is still enough for most people), but OTOH I don't understand the
> obsession for 64bit. 32bit is more than enough on a 32bit system.
There are big companies out there that require thousands of
disks. Many don't want to use hardware raid, they just want JBOD.
There are installations today with 2k-4k disks covering the gamut from
massive databases to HPC to research facilities. Today.
A 32bit dev_t with the 12/20 Linus split provides 64k minors.
That's 16k disks with our current 15-partitions-per limit. But if
someone wants 35 partitions (I've seen that somewhere) you're down to
8k. And the places using 2-4k disks today will be getting to 8k disks
soon after 2.6 becomes usable, if not before. They will likely hit 16k
disks before 2.6 becomes an afterthought.
> Somehow it sounds that we just have to introduce a huge dev_t and all our
> problems are magically solved and I doubt that. If people want to encode
64bit dev_t is not a panacea. However, if we have to do this
change, we want to do it once. This only solves the space issue. All
of the other issues, such as naming, are orthogonal to this change.
Holding one change until everything else has been written is silly.
> (Slowly I'm getting the feeling that there is some sort of 64bit dev_t
> conspiracy going on here, with the amount of answers I'm (not) getting
> here.)
There is no conspiracy. Everyone agrees we need more dev_t
space. Peter, Andries, and others see it like I do; we only want to do
this once, and we already can see a day when 20bits of minors isn't
enough.
Joel
--
Life's Little Instruction Book #207
"Swing for the fence."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2003-03-31 17:14 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-27 20:27 64-bit kdev_t - just for playing Andries.Brouwer
2003-03-27 22:12 ` Roman Zippel
2003-03-27 22:55 ` Alan Cox
2003-03-27 23:19 ` Roman Zippel
2003-03-27 23:48 ` Greg KH
2003-03-28 9:47 ` Roman Zippel
2003-03-28 18:05 ` Joel Becker
2003-03-28 18:48 ` Roman Zippel
2003-03-31 8:31 ` bert hubert
2003-03-31 8:52 ` Roman Zippel
2003-03-31 17:24 ` Joel Becker [this message]
2003-03-31 21:32 ` Roman Zippel
2003-03-31 22:18 ` Alan Cox
2003-03-31 23:42 ` Roman Zippel
2003-04-01 14:42 ` Alan Cox
2003-04-01 16:35 ` Greg KH
2003-04-02 13:02 ` Roman Zippel
2003-04-01 14:42 ` Alan Cox
2003-04-01 16:52 ` Christoph Hellwig
2003-04-01 21:59 ` H. Peter Anvin
2003-04-02 7:12 ` Christoph Hellwig
2003-04-02 7:22 ` H. Peter Anvin
2003-03-31 23:45 ` Joel Becker
2003-03-31 23:07 ` Joel Becker
2003-03-31 23:35 ` Roman Zippel
-- strict thread matches above, loose matches on Subject: below --
2003-04-09 18:40 James Bottomley
2003-04-09 20:54 ` Roman Zippel
2003-04-10 2:19 ` James Bottomley
2003-04-10 12:47 ` Roman Zippel
2003-04-10 15:30 ` James Bottomley
2003-04-10 23:53 ` Roman Zippel
2003-04-11 0:01 ` David Lang
2003-04-11 0:17 ` Roman Zippel
2003-04-11 0:47 ` Joel Becker
2003-04-11 1:11 ` Roman Zippel
2003-04-09 18:36 Andries.Brouwer
2003-04-09 21:11 ` Roman Zippel
2003-04-01 18:32 Andries.Brouwer
2003-03-31 23:41 Badari Pulavarty
2003-03-31 23:54 ` William Lee Irwin III
2003-03-31 23:55 ` Joel Becker
2003-04-02 12:18 ` Roman Zippel
2003-04-02 17:31 ` Badari Pulavarty
2003-04-02 22:03 ` H. Peter Anvin
2003-04-03 10:09 ` David Lang
2003-04-03 11:14 ` Lars Marowsky-Bree
2003-04-03 12:13 ` Roman Zippel
2003-04-03 13:37 ` Andries Brouwer
2003-04-03 14:01 ` Roman Zippel
2003-04-07 15:02 ` H. Peter Anvin
2003-04-07 20:10 ` Roman Zippel
2003-04-07 21:57 ` Roman Zippel
2003-04-07 22:43 ` Kevin P. Fleming
2003-04-08 15:22 ` Roman Zippel
2003-04-08 22:53 ` Werner Almesberger
2003-04-08 23:11 ` David Lang
2003-04-08 23:47 ` Werner Almesberger
2003-04-08 23:58 ` Kevin P. Fleming
2003-04-08 23:56 ` H. Peter Anvin
2003-04-08 23:06 ` Andrew Morton
2003-04-09 0:40 ` Roman Zippel
2003-04-09 1:02 ` Joel Becker
2003-04-09 1:25 ` Roman Zippel
2003-04-09 16:42 ` Roman Zippel
2003-04-09 0:21 ` Roman Zippel
2003-04-11 9:58 ` Pavel Machek
2003-04-08 15:29 ` Roman Zippel
2003-03-28 15:33 Andries.Brouwer
2003-03-28 15:49 ` Roman Zippel
2003-03-28 11:46 Andries.Brouwer
2003-03-28 11:57 ` Roman Zippel
2003-03-28 11:10 Andries.Brouwer
2003-03-28 11:36 ` Roman Zippel
2003-03-30 20:05 ` H. Peter Anvin
2003-03-30 20:13 ` Roman Zippel
2003-03-27 22:37 Andries.Brouwer
2003-03-27 22:55 ` Roman Zippel
2003-03-27 1:09 Andries.Brouwer
2003-03-27 19:23 ` Roman Zippel
2003-03-30 20:10 ` H. Peter Anvin
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=20030331172403.GM32000@ca-server1.us.oracle.com \
--to=joel.becker@oracle.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=Wim.Coekaerts@oracle.com \
--cc=ahu@ds9a.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.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