Messages in this thread | | | Date | Sun, 06 Jun 1999 18:37:14 -0700 | From | "H. Peter Anvin" <> | Subject | Re: Migrating to larger numbers |
| |
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/
| |