Re: SCSI disk naming problem
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, it is always named "da0"; ... 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? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 how you're handling the redundancy; either you do it inside the kernel in which case the resulting device has a virtual path, or you do it outside in which case you have two paths which point to the same device. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 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 than this will be meaningless. As long as you don't move a hard disk from one bus on the controller to the other 8-) -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 than this will be meaningless. 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 you do exactly the same thing. Having long device names is confusing to users who only have one disk controller (and I'd bet this is the vast majority). It took me a long The vast majority has just one disk. Given the fast growth in disk sizes, that majority will not decrease. time to grok the syntax of Solaris device names and I still get confused about this. Commercial or free doesn't have anything to do with this issue...this scheme would force users to remember and type extra characters that many of them don't need. (/dev/da0s1a is long enough, but /dev/dac0t0d0s1a is a little ridiculous for someone that has only one controller and one drive.) If you want to *SOLVE* the problem, then make the disk wiring happen before the kernel is booted. After all, we have a real cute boot loader that can definately load the /boot/disk.wire file 8-) The problem after all is *NOT* one of names but that disks not change names unless the administrator wishes so. It doesn't matter the least how we call them. [snip] Cheers, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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, rz1, rz2, ... ). This was very nice. 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 than this will be meaningless. As long as you don't move a hard disk from one bus on the controller to the other 8-) Yes something like dac0t0... is realy nice - but AFAIK it's not general enough for fibre channel. The main point is that I only see this problem with removeable disks and other kind of SCSI-devices, which I usually wire down. Most of my fixed disks are running with vinum. vinum is able to handle if a drive has changed it's ID and/or name. It's an important thing to have something like this if you want to be able to hotplug a drive (or power up later). Sometimes it's getting another name than it would have after reboot! -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. -Jin 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 ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? , To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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. 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 installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? no, read the kernel LINT config file. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[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 dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. 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 PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. It depends on what you mean by "manually". Presumably, these 100+ hosts have fairly similar kernel configurations, so you only need to build a small number of "wired down" kernels, and then distribute these out to the hosts. I've found that that having wired down SCSI devices is a Good Thing (TM), and it's one of the first things that I fix when I start building kernels for a new version of FreeBSD. I guess I've just gotten used to it. Bruce. I guess you missed the point that I do want to wire down the name. This is the original debate. But, I do not want to wire down the name by hand. The system should be able to take care this simple thing. As you mentioned, digit UNIX does it, Solaris does it, why not FreeBSD? Because it is FreeWare so we cannot do some thing good as commercial UNIXs do? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[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 presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? [ ... ] 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 like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. You can pretty easily write a script to create device nodes named whatever you want. As long as the major and minor numbers are correct, you can call what would be /dev/da0a /dev/dac0t0d0a or whatever you like. I think it is possible, however, to come up with a somewhat reasonable naming scheme within the current framework. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. I would suggest that you come up with a standard naming scheme, and then use it across all of your machines. You could do something like: controller ahc0 controller ahc1 controller ahc2 controller scbus0 at ahc0 controller scbus1 at ahc1 controller scbus2 at ahc2 device da0 at scbus0 target 0 unit 0 device da1 at scbus0 target 1 unit 0 device da2 at scbus0 target 2 unit 0 ... device da14 at scbus0 target 14 unit 0 device da20 at scbus1 target 0 unit 0 device da21 at scbus1 target 1 unit 0 ... device da34 at scbus1 target 14 unit 0 device da40 at scbus2 target 0 unit 0 device da41 at scbus2 target 1 unit 0 ... device da54 at scbus2 target 14 unit 0 If you've got reasonably consistent controller hardware across the machines, you could use one wiring setup like the one above for all the machines. If you have different controller drivers on the different machines, you could probably just elminate the controller-bus wiring and go from there. You can design a maximal wire-down configuration for your largest machine, and it should just work on smaller machines. For instance, if your large machine has 7 SCSI busses and 15 disks per chain, you could set them up as da0 through da134 or so. The wiring configuration, though, would work even for a machine with one disk. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 you } do exactly the same thing. The thing is what is rz44 representing? If kernel spits: "rz44 hardware error 105: write failure -- replace it" Which disk are you going to shutdown and replace without looking at /etc/fstab or /sys/i386/conf/CRUEENT_RUN ? What happens if when you see the message and the host is hosed and needs to be rebooted -- at this time both above files are not available -- ? You have a good point, but I also believe that part of any good disaster recovery scheme is having critical system information (like /etc/fstab, dmesg output, etc.) in hardcopy form. And believe me, we've had enough disasters around here the past six months to see the value of that. :-( I do not think dac5t4 is that worse than rz44 (just two charaters long). Maybe it is better. You immediately know the disk with ID 4 on the SCSI controller 5 is one having trouble. And there's also two more characters you need to remember to type correctly. } Perhaps I am misunderstanding what you mean when you say "by hand". I'm } envisioning an environment where you have a lot of similarly-configured } machines. So you build a kernel (based on GENERIC) to wire down } devices ONE TIME, and distribute that kernel out to all the different } machines. If kernel can do this automatically, no one has to rebuild the kernel any more, and no one has to remember every thing that may reduce sys-admin costs. OK. I'm almost convinced on this point, but I still think that if you're managing 100+ machines, you probably already have an easy mechanism for distributing out kernels to them (think "security patches"). This is special for new users/sys-admins. I personal built 1MB script to setup FreeBSD over the 10 years. It is easy for me to add a couple of lines for wired down the SCSI disk name. But, what is about for the new suers and new sys-admins. Should we make things more easier for them? Making things more easier for new users seems (IMHO) inconsistent with device names that are much longer than they need to be for the common case. } Because it is FreeWare so we cannot do some thing good } as commercial UNIXs do? } } I don't understand this argument. "Free" (i.e. open source) vs. } commercial doesn't have anything to do with this issue. This was some one screamed a couple of years ago. When I pointed out we can do something good like commercial company doing, and one person jumped on top of me and said that Hey, this is FreeWare,but not commercial software, why we should do things like commercial company does? Please don't apply the thinking of one person to an entire community. We've worked together before, and I know you're smarter than that. :-) I'm going to summarize my position, make one final remark, and then get out of the way. 1. I agree that wiring device names down is a good thing. 2. I think that this probably should be the default behavior, but I haven't put enough thought into it to be completely convinced. 3. I disagree with your proposal for longer, more descriptive, device names. I think that it will make the system harder to use for a majority of installations. Ultimately, changing the status quo is going to involve someone (either yourself or someone else) writing up some patches and submitting them for -core's approval. Cheers, Bruce. PGP signature
Re: SCSI disk naming problem
[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 PROTECTED] said. } } So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want } to be short, but anything shorter than this will be meaningless. } } 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 you } do exactly the same thing. The thing is what is rz44 representing? If kernel spits: "rz44 hardware error 105: write failure -- replace it" Which disk are you going to shutdown and replace without looking at /etc/fstab or /sys/i386/conf/CRUEENT_RUN ? What happens if when you see the message and the host is hosed and needs to be rebooted -- at this time both above files are not available -- ? I do not think dac5t4 is that worse than rz44 (just two charaters long). Maybe it is better. You immediately know the disk with ID 4 on the SCSI controller 5 is one having trouble. If you have just one disk, I think two charaters will not be a big deal anyway. However, it will be great help to identify the disk by this two charaters. } Having long device names is confusing to users who only have one disk } controller (and I'd bet this is the vast majority). It took me a long Yes or No. I know at least 7-10 sites running 50 - 100 nodes of FreeBSD. I believe there are much more than I know. How many FreeBSD servers are running in this world? A single node FreeBSD server on this planet can be a lot. A single disk FreeBSD users could be the majority at this monment, do we want more and more FreeBSD servers runnning around the world? So, we should think about the future. } time to grok the syntax of Solaris device names and I still get confused } about this. Commercial or free doesn't have anything to do with this } issue...this scheme would force users to remember and type extra } is good. (I did } miss a message or two in the middle of your discussion, apparently, and } that may have contributed to my apparently confusion.) } } But I think your proposed long names are confusing, and I claim that } that rebuilding a kernel to get wired-down device names is easy. } } Perhaps I am misunderstanding what you mean when you say "by hand". I'm } envisioning an environment where you have a lot of similarly-configured } machines. So you build a kernel (based on GENERIC) to wire down } devices ONE TIME, and distribute that kernel out to all the different } machines. If kernel can do this automatically, no one has to rebuild the kernel any more, and no one has to remember every thing that may reduce sys-admin costs. This is special for new users/sys-admins. I personal built 1MB script to setup FreeBSD over the 10 years. It is easy for me to add a couple of lines for wired down the SCSI disk name. But, what is about for the new suers and new sys-admins. Should we make things more easier for them? } Because it is FreeWare so we cannot do some thing good } as commercial UNIXs do? } } I don't understand this argument. "Free" (i.e. open source) vs. } commercial doesn't have anything to do with this issue. This was some one screamed a couple of years ago. When I pointed out we can do something good like commercial company doing, and one person jumped on top of me and said that Hey, this is FreeWare,but not commercial software, why we should do things like commercial company does? I was scared I had bad approching for FreeWare. Now I think there is nothing wrong if we can use some good idea from any one including commercial sector. So, that is why I would like to tune the name on SCSI disks. -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
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 contains some piece of random-generated junk that works as a disk ID. The association of the disk number and this ID is also written into resmanager. Resmanager is a thing like sysctl but much more braindamaged and difficult to use, and its contents is saved to disk when the system is stopped. So when the system boots next time it reads in the resmanager database and tries to associate the disks with known ID to the same number which was assigned to them last time. The problem of this method is getting rid of the stale disk ID left in the resmanager, so some way should be provided to do that (and better it be better than in UnixWare). I guess this thing would be rather easy to implement in FreeBSD: instead of the on-disk resmanager database we can use the already existing mechanism of the 3rd stage loader configuration files. And the changes to the SCSI disk driver should be not too complex too. Such a mechanism has also the second (and I suppose the main) use in UnixWare: it is absolutely neccessary for the MultiPath I/O. That is, a disk may be connected to more than one SCSI card and if one of the access paths crashes another one can still be used. There are two problems: first, how do we know that this is the same disk accessible by two paths ? second, if one of the path crashes what are we going to do on the next reboot not to let the disk get re-assigned to another name ? Both of them are resolved by these disk IDs in the VTOCs. -SB 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 ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
