> > > '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 how you're handling the redund
> > '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 how you're handling the redundancy; either
> > 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
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
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 fo
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 anyt
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
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 co
[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
} > [EM
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 let
If memory serves me right, [EMAIL PROTECTED] wrote:
> [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.
> > >
> > > We
[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.,
> > >
[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 thin
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
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 dac0t0d0, dac0t1d0, ... dac3
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.
>
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, it is
always named "da0";
if two disks are ins
> 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 n
18 matches
Mail list logo
