In article [EMAIL PROTECTED] you wrote:
Current FreeBSD SCSi disk naming mechanism is problem for using more than
one disks in the chain during the disk failure.
The problem is that the name is not fixed with is SCSI ID. e.g.,
if one disk is presented in the chain, regardless its SCSI ID,
Is there problem with fixed disk naming mechanism?
'Path based names' do not deal with systems that have multiple
paths to the same device. For example, if I have two host adapters
talking on the same bus for redundancy, which name to I give to the
devices on the bus?
That depends on
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
[snip]
That's an interesting argument on the part of a few people. The
commercial UNIX I first adminned had wired down, short names for disks
(rz0, rz1, rz2, ... ). This was very nice.
This one does not
On Fri, 1 Oct 1999, Bruce A. Mah wrote:
If memory serves me right, [EMAIL PROTECTED] wrote:
This one does not resolve the controller problem either as
[EMAIL PROTECTED] said.
So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want
to be short, but anything shorter
On Sat, Oct 02, 1999 at 01:15:53PM +0300, Narvi wrote:
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
[snip]
That's an interesting argument on the part of a few people. The
commercial UNIX I first adminned had wired down, short names for disks
(rz0,
See LINT on details of how to wire down scsi devices...
Your proposal doesn't take adding a second scsi card into account.
Well, I did not mean that has to be da0, da1, etc., but similar thing
like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what
disk is.
A few people does not
See LINT on details of how to wire down scsi devices...
Your proposal doesn't take adding a second scsi card into account.
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:
Current FreeBSD SCSi disk naming mechanism is problem for using more than
one disks in the chain during the disk failure.
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:
Current FreeBSD SCSi disk naming mechanism is problem for using more than
one disks in the chain during the disk failure.
The problem is that the name is not fixed with is SCSI ID. e.g.,
if one disk is presented in the chain, regardless its SCSI
[EMAIL PROTECTED] wrote:
If memory serves me right, [EMAIL PROTECTED] wrote:
See LINT on details of how to wire down scsi devices...
Your proposal doesn't take adding a second scsi card into account.
Well, I did not mean that has to be da0, da1, etc., but similar thing
like
[EMAIL PROTECTED] wrote...
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:
Current FreeBSD SCSi disk naming mechanism is problem for using more than
one disks in the chain during the disk failure.
The problem is that the name is not fixed with is SCSI ID. e.g.,
if one disk is
If memory serves me right, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
} Well...I personally prefer the short names. On systems with multiple
} controllers, the commercial UNIX I used (Ultrix) just continued its
} numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ... FreeBSD lets
[EMAIL PROTECTED] wrote:
} That's an interesting argument on the part of a few people. The
} commercial UNIX I first adminned had wired down, short names for disks
} (rz0, rz1, rz2, ... ). This was very nice.
}
} This one does not resolve the controller problem either as
} [EMAIL
Narvi wrote:
See LINT on details of how to wire down scsi devices...
Your proposal doesn't take adding a second scsi card into account.
UnixWare has a kind od solution for this: when they create
the VTOC table (an analog of the BSD disk label) on the disk
they have a field in it that
13 matches
Mail list logo
