Re: memory waste in fs/devices.c/kdevname()

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Fri, 18 Dec 1998 23:55:45 +0100 (CET)

>
> On Fri, Dec 18, 1998 at 03:27:01PM +0000, Jamie Lokier wrote:
> > On Fri, Dec 18, 1998 at 12:41:12PM +0000, Tigran Aivazian wrote:
> > > static char buffer[32];
> > > sprintf(buffer, "%02x:%02x", MAJOR(dev), MINOR(dev));
> > > But the maximum length of "%02x:%02x" is 6 bytes (including '\0').
>
> You mean the length ... (it's constant)
>
> > > We can throw in a couple of bytes "for good measure" and have
> > > static char buffer[8] but why on earth do we declare it as [32]?
> >
> > You're right. Better change it to [42] ready for 64-bit major & minor
> > numbers...
>
> ... what would result in 34 bytes (%08x%08x:%08x%08x), if my
> brain-integrated calculator has no builtin Pentium.
> 42 of course, is a much more beautiful number ;-)
>
> Seriously: Are we really going to 64:64 bits for maj:min device numbers ?
> 16:16 would be fine for the next 100 years (nobody wants to manage a box
> harddisk with 64k terminals?), but we can go 32:32, if we think it's
> necessary. But 64:64 ???

16:16 is probably too few if you want to assign sparse minors, which is IMHO
a good thing. Currently, e.g. inserting a SCSI disk on a completely
different host causes many disk's minors to be changed, so e.g. clients of
the NFS server after disk addition/removal will have stale NFS handles.
If on the other side the minor included HBA number, channel, id, lun and
partition in it, such problems would not exist. I agree 64:64 is too much,
but IMHO it would be good to choose something like 16:48 or even 12:52. And

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.1.130 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/