Folks,
Who is tracking the 32bit dev_t effort for 2.5? There are
already existing installations with 500 to 1000 disks attached to a
system, and I don't know that Linux really wants to wait four years to
get there!
If someone could point me to a current patch or any current
information about the issues, I'd really appreciate it.
Joel
--
Life's Little Instruction Book #182
"Be romantic."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
Joel,
Linux doesn't really need a 32 bit kdev_t structure to support 1000
disks. There is plenty of device space available to support over 1500
disks by modifying the linux scsi layer.
Thanks
-steve
Joel Becker wrote:
>Folks,
> Who is tracking the 32bit dev_t effort for 2.5? There are
>already existing installations with 500 to 1000 disks attached to a
>system, and I don't know that Linux really wants to wait four years to
>get there!
> If someone could point me to a current patch or any current
>information about the issues, I'd really appreciate it.
>
>Joel
>
>
>
On Tue, Jan 21, 2003 at 02:29:17PM -0700, Steven Dake wrote:
> Linux doesn't really need a 32 bit kdev_t structure to support 1000
> disks. There is plenty of device space available to support over 1500
> disks by modifying the linux scsi layer.
First, that's an approach that removes space from other devices.
In addition, I suspect we'll see 2000 disk systems before we see 2.8.
Joel
--
"I am working for the time when unqualified blacks, browns, and
women join the unqualified men in running our overnment."
- Sissy Farenthold
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Tue, Jan 21, 2003 at 01:56:02PM -0800, Joel Becker wrote:
> On Tue, Jan 21, 2003 at 02:29:17PM -0700, Steven Dake wrote:
> > Linux doesn't really need a 32 bit kdev_t structure to support 1000
> > disks. There is plenty of device space available to support over 1500
> > disks by modifying the linux scsi layer.
>
> First, that's an approach that removes space from other devices.
> In addition, I suspect we'll see 2000 disk systems before we see 2.8.
Of course, we know the solution is /dev/disk, as mentioned by Linus at
least a couple times, which eliminates a lot of dev_t limitation
issues... :)
Jeff
On Tue, 2003-01-21 at 21:29, Steven Dake wrote:
> Joel,
>
> Linux doesn't really need a 32 bit kdev_t structure to support 1000
> disks. There is plenty of device space available to support over 1500
> disks by modifying the linux scsi layer.
You run out of assigned major/minor numbers. There is a sick hack that
steals other device idents but thats not usable in a production environment.
32bit dev_t IMHO is essential to 2.6. Essential enough that if its not in
the base 2.6 all the vendors have to get together and issue a Linus
incompatible but common 32bit dev_t interface.
> Who is tracking the 32bit dev_t effort for 2.5?
Once or twice a year I build a kernel with 32bit or 64bit dev_t.
Every now and then submit a few patches so that doing so
remains easy. The last real change was the change in prototype
of the VFS *_mknod functions.
: 32bit dev_t IMHO is essential to 2.6. Essential enough that if its not
: in the base 2.6 all the vendors have to get together and issue a Linus
: incompatible but common 32bit dev_t interface.
The main point to decide would be the external dev_t format.
Of course the format must be compatible with existing filesystems
and binaries. For example,
#define MAJOR(dev) ((unsigned int)(((dev) & 0xffff0000) \
? ((dev) >> 16) & 0xffff : ((dev) >> 8) & 0xff))
#define MINOR(dev) ((unsigned int)(((dev) & 0xffff0000) \
? ((dev) & 0xffff) : ((dev) & 0xff)))
#define MKDEV(ma,mi) ((dev_t)((((ma) & ~0xff) == 0 && ((mi) & ~0xff) == 0) \
? (((ma) << 8) | (mi)) : (((ma) << 16) | (mi))))
This is 1-1 on nonzero majors (and zero major, 8-bit minor).
Once the decision has been made on the size of dev_t and the
computation of major,minor given a dev_t, it is straightforward
to implement that decision. Unfortunately not only the kernel
but also glibc must be changed.
In glibc one needs to fix in sysdeps/unix/sysv/linux
the files sys/sysmacros.h, bits/stat.h, ustat.c, xmknod.c.
In the kernel there are lots of tiny fixes needed because
people did not distinguish between int and dev_t and kdev_t.
Nothing major.
(Anyone can boot a 2.5 kernel with 32-bit dev_t by changing
include/asm-i386/posix_types.h
(change the line "typedef unsigned short __kernel_dev_t;"
to what is desired, e.g. s/short/int/) and changing
include/linux/kdev_t.h
(change the typedef for kdev_t to have e.g. unsigned int,
set KDEV_MINOR_BITS and KDEV_MAJOR_BITS to 16,
change the 0xff in the definition of major and minor to 0xffff,
change the definitions of MAJOR, MINOR, MKDEV as above).)
[Warning: I do such things and it works. But if you do so,
it may well destroy your filesystems. A complete patch has
minor fixes all over the place.]
Andries
On Fri, Jan 24, 2003 at 11:04:45PM +0100, [email protected] wrote:
> Once or twice a year I build a kernel with 32bit or 64bit dev_t.
> Every now and then submit a few patches so that doing so
> remains easy. The last real change was the change in prototype
> of the VFS *_mknod functions.
It's good to know that the actual changes are small, but I was
specifically wondering what the status was as far as inclusion. If
there are issues, what are they? Etc.
Joel
--
"In the arms of the angel, fly away from here,
From this dark, cold hotel room and the endlessness that you fear.
You are pulled from the wreckage of your silent reverie.
In the arms of the angel, may you find some comfort here."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
Followup to: <[email protected]>
By author: [email protected]
In newsgroup: linux.dev.kernel
>
> The main point to decide would be the external dev_t format.
> Of course the format must be compatible with existing filesystems
> and binaries. For example,
>
> #define MAJOR(dev) ((unsigned int)(((dev) & 0xffff0000) \
> ? ((dev) >> 16) & 0xffff : ((dev) >> 8) & 0xff))
> #define MINOR(dev) ((unsigned int)(((dev) & 0xffff0000) \
> ? ((dev) & 0xffff) : ((dev) & 0xff)))
> #define MKDEV(ma,mi) ((dev_t)((((ma) & ~0xff) == 0 && ((mi) & ~0xff) == 0) \
> ? (((ma) << 8) | (mi)) : (((ma) << 16) | (mi))))
>
> This is 1-1 on nonzero majors (and zero major, 8-bit minor).
>
I thought we had already decided:
12 bits major : 20 bits minor
The zero major is used for dev_t compatibility, of course.
I personally still prefer 32:32, but I got voted down.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64