Re: Migrating to larger numbers

H. Peter Anvin (hpa@transmeta.com)
Sun, 06 Jun 1999 18:37:14 -0700

Guest section DW wrote:
>
> hpa: I'd still like to suggest a 64-bit dev_t.
>
> aeb: I entirely agree. With 32 the partitioning may become significant
> and 16+16 is suboptimal. With 64 there is no reason to not just
> use 32+32. However, some things I haven't checked (or have forgotten
> again), like: is raw_inode->i_block[1] guaranteed to be zero today
> for a device node? At first sight this seems not to be the case,
> which means that for a 64-bit dev_t a "conversion" is required,
> namely finding all device nodes on the file system and writing
> a zero into the presently unused raw_inode->i_block[1].
>

hpa: I suspect that you're right -- and Ulrich seems to agree: it's
easier to make glibc work using your convention; we can reassign
the anonymous devices to another major (although that will break
code looking for those.) My suggestion, however, for the on-disk
system, is the following:

If the dev is too big for the current format, stick -1 in the
block pointer used by the current format, and use the N (for
1 <= N <= 4, depending on the filesystem) subsequent block
pointers to hold the real device number.)

I suggest, as you say, a 32:32 split (it's simple).

-hpa

-
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/