[Gllug] SCSI and /dev

[Mike Brodbelt]

On Wed, 2004-03-03 at 20:12, Bruce Richardson wrote:

> It's going to be there till at least 2.7, this has been assured.
> 
> > , so
> > any effort invested in it at this point is likely to be a dead end
> > somewhere not too far down the line.
> 
> 2.8 is a while away.

True, and the fact that support for it isn't going to vanish in the
immediate future should give comfort to people who are using devfs in
production today, but I would say it's impending demise (albeit a way
off) is a good reason not to *start* using it now.

> > I've never really understood the urge to have a /dev with only valid
> > device nodes in it. I care *far* more about persistent device naming,
> > which udev offers, and devfs doesn't. In between SCSI disks, firewire
> > storage, and USB card readers, I can't use fstab mounting[1] for my
> > removable media. Running rescan-scsi-bus is a hack at best... The
> > presence of a few hundred device nodes, which do nothing
> 
> It isn't a few hundred.  On a standard Debian system it's 1200 to 1600.
> On a fresh Red Hat 9 install it's over 9000.  With devfs you can cut
> that down to about 70.

On my box, /dev and subdirectories consumes 456 blocks. There's a bit of
stuff in subdirectories, but not much. 456 blocks, at 4k per block costs
somewhere between 0.2 and 0.6 pence, depending on how pricey your disks
are. Yes, it's technically wasted, but does it really matter?  Accepting
designed in race conditions just to trim /dev seems like the wrong side
of the bargain to me.

>From a performance perspective, programs that use entries in /dev tend
to know which entries they need, so rarely enumerate all those entries
and incur a performance hit. When a program does enumerate all the
entries, devfs will merrily DOS the system with spurious modprobe
attempts...

Mike.


-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug