In message <9412211518.AA27146@kuma.web.net>, Greg A. Woods writes:
> 
> The point is to have the lock files out in the filesystem so that they
> can be investigated and maniuplated....
> 

Yeah, but what are you going to do with a lock file?  So you know something
is holding a lock on the lock file.  Is that any different than having the
locking done in the kernel?  Why the extra file?  Why the clutter?  If the
locking can be done in a machine independant way, and in a reasonable
amount of code, why not?


> In case it escaped your attention, the SysV device names are extremely
> descriptive (and thus useful), esp. for SCSI devices.  For example,
> c1t2d0s5 is {controller-1}, {scsi_target-2}, {disk_unit-0}, and
> {partition/slice-5}.  Hard to forget what physical thing that name
> points to, eh?

Hell, yeah they are descriptive, after you sit and think about it for
a while.  I personally like "sd0", etc better.  I just wish that they
had a "home" of their own to live in... ;-)


> I wouldn't argue with splitting these names intoe sub-directories where
> appropriate, but for SCSI, I don't think the number of addressable units
> is really that high to require separate directories for each target or
> whatever.

Look at my previous post, on a development machine, running 3 or 4 different
databases, with 15+ disks, the naming gets into the 60's quite quickly when
you count raw and block devices (as well as the b and c partitions).


--Toby.
*----------------------------------------------------------------------------*
| Tobias Weingartner | Email: weingart@BrandonU.Ca | Need a Unix sys-admin?  |
| Box 27, Beulah, MB |-----------------------------| Send E-Mail for resume, |
| R0M 0B0, Canada    | Unix Guru, Admin, Sys-Prgmr | and other details...    |
|----------------------------------------------------------------------------|
|      %SYSTEM-F-ANARCHISM, The operating system has been overthrown         |
*----------------------------------------------------------------------------*