lkml.org 
[lkml]   [1999]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.085 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site