[nSLUG] What kernel for inotify?

George White aa056 at chebucto.ns.ca
Fri Sep 16 12:14:17 ADT 2005

On Fri, 16 Sep 2005, Stephen Gregory wrote:

> George White wrote:
> > Looking
> > that the discussions of IDE support will certainly encourage you to make sure
> > your next system uses SCSI disks.
> Linux IDE/SATA support is better then SCSI support. The majority of IDE 
> controllers are Intel or VIA, and to a lesser extent Nvidia and SiS. 
> All of these controllers are fully supported by Linux. The Intel and Via 
> controllers are the most common and best tested chips besides the CPUs. 
> The problems people run into is with the addon IDE/SATA controllers. 
> Especially the psuedo raid controllers.

"Better" is too vague.  My feeling is that if a vendor wants to write
drivers for a SCSI controller it isn't impossible to get a robust driver.
IDE drivers have more work to do and are often blamed for things like
excessive stack demands on large filesystems under heavy load, in
particular, fsck and xfs_fsr are prone to failure.  Some of the problems
will go away on 64-bit machines that can use more registers.
> SCSI support is not as well tested. Also, vendors, such as Adaptec, have 
> not supported Linux as well as they should.

Mainstream SCSI devices, e.g., disks with onboard controllers, are heavily
used in large servers and clusters.  Support for thinks like SCSI scanners
and film recorders is a problem.  If "better" means you can use devices
from any vendor, SCSI may not be a good thing, but if "better" means
choosing a system that uses can handle heavy workloads on disks and tapes,
SCSI is 

> > With the 2.6.12.x kernels in FC4 my biggest issue has been the time it takes
> > udev to create a new /dev/ttyUSBn entry (e.g., after plugging in a USB device).
> UDEV is an ugly ugly hack that was pushed into the kernel before UDEV 
> was ready. The kernel side of UDEV may be excellent (I wouldn't know). 
> The user space side of UDEV is still incomplete and packed full of shell 
> script magic.

Yes, managing /dev is like mail user agents -- all available solutions
suck.  I think people accepted the udev approach when it became clear that
devfs had issues that couldn't be overcome.  There are serious problems
with udev -- many Palm devices create /dev/ttyUSB[n] and /dev/ttyUSB[n+1]
entries, but only one of the entries is used.  I've been using the
odd-numbered entry, but then I connect my GPS thru a USB2serial gizmo and
I need the even-number entry.  That appears to be too much for the current
udev configuration tools to deal with.

Don't get the impression that Windows XP handles this either.  It seems to
do some static configuration when a new device is first connected, but 
as soon as you have more than a couple devices wierdness occurs and you
end up trapped in an endless "reconfigure/reboot/..." loop.

George White <aa056 at chebucto.ns.ca> <gnw3 at acm.org>
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia  B3Z 2G6


More information about the nSLUG mailing list