lkml.org 
[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
On Wed, 5 Aug 1998, Richard Gooch wrote:

>joke. Apart from being incredibly ugly (having a huge /dev), having
>lots of inodes means that directory searches are quite slow.

1. You can delete everything you don' t need from /dev/. If you are lazy
probably you also don' t care to tune a lot of other probably more
performance sensitive things in the kernel.

2. I don' t know very well the fs code but I don' t think the problem
is the number of inodes, but instead the number of file entry in the
directory /dev/. So dividing /dev/ in /dev/block /dev/char for example
would speed up things I think.

root@dragon:/dev# mkdir block
root@dragon:/dev# cd block/
root@dragon:/dev/block# cp ../hda3 . -a
root@dragon:/dev/block# ls -l
total 0
brw-rw---- 1 root disk 3, 3 May 6 1997 hda3
root@dragon:/dev/block# mount /dev/block/hda3 /park
root@dragon:/dev/block# ls /park
architettura.tar.gz lab2.tar.gz tgz
debian lost+found
gcc mame
root@dragon:/dev/block# mount
/dev/hda1 on / type ext2 (rw)
proc on /proc type proc (rw)
/dev/hdc on /cdrom type iso9660 (ro,noexec,nosuid,nodev,unhide)
/dev/block/hda3 on /park type ext2 (rw)

I don' t know if devfs is so malleable/configurable.

Andrea[s] Arcangeli


-
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

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