Messages in this thread | | | Date | Thu, 6 Aug 1998 16:49:50 +1000 | From | Richard Gooch <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
Andrea Arcangeli writes: > On Thu, 6 Aug 1998, Richard Gooch wrote: > > >> >Erm, if you just move all block devices into their own subdirectory, > >> >and assuming the bulk of /dev bloat is due to block devices > >> >(reasonable, when you consider the zillions of possible SCSI discs > >> >when we break the 16 disc limit), then searching through /dev/block is > >> >nearly as long as searching /dev with everything in it. > >> > >> With the current inode scheme nobody force you to put all blocks device in > >> the same directory. I will use /tmp/myhd to be fast. > > > >That looks like a hack to me. > > Isn' t devfs an hack?
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
| |