On Sat, 2002-06-08 at 00:33, Andrew Basterfield wrote: > So what would happen if you have devfs and more than 128 (IIRC) SCSI > disks? I would extend the kernel to handle more, just like RedHat do now, and did previously when the limit was 16. > You will be outside the major/minor address space - this is what > devfs was designed for No, devfs was designed to _manage_ device numbers, not do away with them. The address space is not going, and it's not changing in size. > so would 'find' break on the 129th disk? find relies (relied) on /dev entries to work out which filesystem it's on, so -xdev would probably not work. > If you mount a filesystems using NFS it will have no associated /dev > entry (and hence no majors and minors). That argument doesn't follow, I'm afraid. I'm pretty sure NFS clients get their device numbers from the server - which is why, if you move an export from one filesystem to another, all the clients need to remount. > This doesn't seem to bother 'find' (or indeed any other POSIX utility). Really. From the FAQ: "Please note that using dynamically allocated block device numbers may break the NFS daemons [when the numbers change]" (see above :) If the NFS daemons break, I suspect very much that the file utilities will also not work. Device numbers are not going away. The kernel interface has been changed so that device drivers may be allocated numbers on the fly - all that means is that you can't pre-encode the major/minor numbers you're interested in (both kernel-side or client-side). Device numbers are required for POSIX. Cheers, Alex.
Attachment:
signature.asc
Description: This is a digitally signed message part