It looks less hackish to me than moving your few "important" inodes!
> >> And the device-file lookup in the case of block devices is done only at
> >> mount time (I hope to be right here ;-) so it' s really not importatnt and
> >
> >Actually, it's done at open(2) time. That's done by mount(8), fdisk(8)
> >and so on. Also if you want to list the directory, it takes more time.
>
> I don' t look at /dev/ from ages.
Fine: you don't. I do. Quite often I've had new discs plugged into my
machine which are taken out again after a while. Not only do I have to
mount discs, I have to look at /dev/sd or /dev/ide/hd to see what's
popped in this time.
> >Mounting isn't the only time you need to access those inodes. Also,
> >think about those with a small CPU: extra (noticable!) delay at boot
> >time is unwelcome.
>
> We are talking of msec on a 486 with a populated /dev/ I guess.
I've just created a directory with 85000 inodes. An inode lookup (near
the end of the directory) takes about 10 ms on my dual PPro 180.
Extrapolating that to 8 million inodes gives us nearly a second.
Doing ls -lF on the directory is simply not possible: I killed it
after waiting 40 minutes.
Moral: a fully populated /dev is a bad idea. A scsidev or devfs
solution is essential.
> BTW, with the exciting idea of using btrees for storing directory entries,
> the inode lookup will be a lot _faster_.
Yes, btrees will be good. You still don't want a fully populated /dev,
though.
> Richard I had to specify that with my arguments I don' t care at all of
> people other than me. I don' t know how much useful can be devfs for
> distributors or for people that use Linux only to repartition HDs. I can
> tell that devfs is useful for me _only_ for the major/minor numbers thing.
> If in the near future there will be a cleaner way to handle >256 minor
> numbers devfs will be only overhead _for_me_.
OK, fine. Then don't configure it. I don't see that as a reason to not
have it available in the kernel, though. Different people, different
needs.
Regards,
Richard....
-
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.altern.org/andrebalsa/doc/lkml-faq.html