greetings,
it has been a long time and i do not recall all the specifics
if one loads CentOS Linux on a machine with an PATA IDE or SCSI hard drive interface then i should be able to interchange that drive on virtually _ANY_ machine with an PATA IDE or SCSI respectively right?? (ignore physical connector differences on SCSI)
i believe the answer(s) to be yes...
now, what about the newer SATA? will it hold true there as well or are there enough minor differences in SATA creation and growth where one could run into an occasional problem?
the bottom line appears to be that almost _ALL_ relevant hardware drivers from the past and the present are included in the distribution correct?
can anyone comment on any major recent "gotchas" or other relevant situations they experienced in moving drives from machine to machine or ???
tia and regards,
- rh
-- Robert Hanson Abba Communications http://www.abbacomm.net
On Thu, 2005-08-18 at 11:07, Robert Hanson wrote:
greetings,
it has been a long time and i do not recall all the specifics
if one loads CentOS Linux on a machine with an PATA IDE or SCSI hard drive interface then i should be able to interchange that drive on virtually _ANY_ machine with an PATA IDE or SCSI respectively right?? (ignore physical connector differences on SCSI)
i believe the answer(s) to be yes...
now, what about the newer SATA? will it hold true there as well or are there enough minor differences in SATA creation and growth where one could run into an occasional problem?
the bottom line appears to be that almost _ALL_ relevant hardware drivers from the past and the present are included in the distribution correct?
can anyone comment on any major recent "gotchas" or other relevant situations they experienced in moving drives from machine to machine or ???
I was very surprised that things worked well when moving one IDE drive to another system. It booted up and detected a number of differences in the motherboard chip sets and removed and installed the correct drivers for the new system. Went much smoother than I hoped.
The biggest problem you may run into is if you use a different architecture for the CPU. There could be some issues there where loading the correct kernel for the new system prior to moving the drive maybe prudent.
As to SATA I don't have as much experience but the thing to look for is the specific chip set used. I have one motherboard that has two SATA controllers on it. The Silicon chip set was recognized and was usable during the install process. The other which I think was an Intel chip set initially did not see any drives I connected to it. I think since then I have found an option in bios that would resolve this problem. The option made it use a shorter time to detect the drive and this was timing out. However I have not made time to go back and test this.
So if you have the same SATA chip set between systems I don't see any reason this would not work. If they are different then you need to do some additional checking.
Use lspci to get the information on the chip set used.
"Scot L. Harris" webid@cfl.rr.com wrote:
As to SATA I don't have as much experience but the thing to look for is the specific chip set used.
The only issue you might have will be device assignment.
If the distribution/kernel uses an ATA driver, it will be hd. If the distribution/kernel uses a SCSI block driver, it will be sd.
ATA is a single driver build (even if different files).
SCSI is a subsystem (typically a module) with support modules for the host controller (3w-xxxx, aic7xxx, nv_sata, etc...) and host devices (sd, sr, etc... modules).
In a nutshell ...
Many distro/kernels are using the SCSI subsystem for SATA until the changes are merged into the kernel main ATA's code. tree This could have an effect when upgrading and/or changing chispets if a driver is merged into the standard ATA code tree.
[ SIDE NOTE: This isn't just a Linux approach, as other vendors often use the modular SCSI subsystem to support various ATA devices that are not in the OS' ATA codebase. ]
On Thu, 2005-08-18 at 08:56 -0700, Bryan J. Smith wrote:
[ SIDE NOTE: This isn't just a Linux approach, as other vendors often use the modular SCSI subsystem to support various ATA devices that are not in the OS' ATA codebase. ]
That's interesting. When stuff like this pops up (like when SCSI was used for everything from CD Burners to flash drives) I often wonder how other Operating Systems actually handle this under the covers.
Preston
thank you Scot, Bryan, Preston and others that will respond,
i asked because i am going through a new hardware cycle...
my last hardware cycle was between the 1.2.13 and 2.0.X linux kernel stages believe it or not... and back then... well, i always hand rolled a kernel optimized to the bare bones servers i would take and hand build.
i guess that i built some solid "forward looking" units as most did not need to be replaced for many years... typically 5 or more and many were simply just upgraded in processor or DRAM and possibly hard drive space etc.
Bryan, i noticed and noted the SATA /dev/sda etc type device assignment issues.
ummmmm will SATA always have SCSI type device assignment or has/will a new assignment be created?
i imagine that it would go so an ATA type device assignment eventually wouldnt it?
bottom line is, just about every type of hard drive storage interface driver (as well as any other relevant driver types) is/are included in the CentOS linux distribution?
thanks
- rh
-- Robert Hanson Abba Communications http://www.abbacomm.net
Robert Hanson roberth@abbacomm.net wrote:
my last hardware cycle was between the 1.2.13 and 2.0.X linux kernel stages believe it or not... and back then...
I started with 0.96 and Yggdrasil.
well, i always hand rolled a kernel optimized to the bare bones servers i would take and hand build.
I pretty much switched to modules/initrd kernels with kernel 2.2+ as well.
Bryan, i noticed and noted the SATA /dev/sda etc type device assignment issues. ummmmm will SATA always have SCSI type device assignment or has/will a new assignment be created?
It's not SATA per se, but the maintainers. E.g., nVidia and volunteers maintain the GPL nv_sata driver.
At this time, libata support is still forthcoming, so the ATA codebase lacks most drivers. There are only a few.
i imagine that it would go so an ATA type device assignment eventually wouldnt it?
Yes. The best "status page" I know of is here: http://linux.yyz.us/sata/sata-status.html
You'll note some say "not suited for libata" meaning they are not ATA-like. E.g., 3Ware's Escalade 8000/9000 series may use SATA devices, but the kernel only talks to its on-board ASIC intelligence, not the SATA channels.
But others, like the nVidia SATA in the nForce, have beta libata support. I suspect they will become part of the ATA codebase and you will use "hd" instead of "sd" (as currently with "nv_sata") in the future.
On Thu, 2005-08-18 at 11:29, Robert Hanson wrote:
bottom line is, just about every type of hard drive storage interface driver (as well as any other relevant driver types) is/are included in the CentOS linux distribution?
Drivers tend to be per controller type and the complication is that the ones you need to boot are detected during the install process and included in the initrd that is built then. If you move the boot drive or clone the system to a machine with a different controller, you have to adjust /etc/modprobe.conf (or conf.modules, or modules.conf or whatever they call it that week...) to include the kernel module you need, and then rebuild the initrd image. It's possible but not much fun to do this from the install disk in rescue mode after the swap.
} -----Original Message----- } From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On } Behalf Of Les Mikesell } Sent: Thursday, August 18, 2005 10:32 AM } To: CentOS mailing list } Subject: RE: [CentOS] using various IDE or SCSI hard drive interfaces } withCentOS Linux questions } } On Thu, 2005-08-18 at 11:29, Robert Hanson wrote: } } > bottom line is, just about every type of hard drive storage interface } driver } > (as well as any other relevant driver types) is/are included in the } CentOS } > linux distribution? } } Drivers tend to be per controller type and the complication is that the } ones you need to boot are detected during the install process and } included in the initrd that is built then. If you move the boot drive } or clone the system to a machine with a different controller, you have } to adjust /etc/modprobe.conf (or conf.modules, or modules.conf or } whatever they call it that week...) to include the kernel module you } need, and then rebuild the initrd image. It's possible but not much } fun to do this from the install disk in rescue mode after the swap. } } -- } Les Mikesell } lesmikesell@gmail.com } } } _______________________________________________ } CentOS mailing list } CentOS@centos.org } http://lists.centos.org/mailman/listinfo/centos
interesting. thanks.
i should be ok and i dont really want to "have to" learn how to do that yet i probably should.
ummm lets say i have a two compaqs.. 1850R and a dl380... they look identical yet obviously would have some minor differences.
mix in some CentOS 4 :-)
and so, if i load and config the 1850R with 4 scsi drives in raid5 array and get functional with CentOS, let's say i want to take all 4 drives and stuff them in correct order in a dl380 *cold*...
possibly different SCSI controllers.... yet nothing CentOS couldnt handle IMHO...
....will that work provided i have done all the low level smartstart cd stuff before hand???
im thinking it should...
i should have the extra hardware to test this soon anyways yet am wondering
- rh
-- Robert Hanson Abba Communications http://www.abbacomm.net
On Thu, 2005-08-18 at 12:47, Robert Hanson wrote:
and so, if i load and config the 1850R with 4 scsi drives in raid5 array and get functional with CentOS, let's say i want to take all 4 drives and stuff them in correct order in a dl380 *cold*...
possibly different SCSI controllers.... yet nothing CentOS couldnt handle IMHO...
Whether it works or not depends on having the correct hard drive module either compiled in the kernel or on the initrd. It may depend on 'how' different the controllers are since some modules cover several variations.
The kernel and initrd are loaded by bios, then the kernel has to be able to load the rest of the modules it needs. Obviously it can't load the hard drive driver module from the hard drive so that has to have already been conveniently stashed in the initrd image. Other modules can be loaded from the hard drive so most other hardware differences will be sorted out on the fly during bootup. You might have to reconfigure your X setup manually or sort out which network interface is which, but at least you are up and running while you do that.
Les Mikesell lesmikesell@gmail.com wrote:
Drivers tend to be per controller type and the complication is that the ones you need to boot are detected during the install process and included in the initrd that is built then.
The difference in this discussion is the fact that the ATA driver and the SCSI subsystem differ greatly. ATA is almost always built statically in the stock kernel. LibATA will offer support for newer ATA services.
But even when it looks like you are configuring a(n) [S]ATA controller, or making an initrd, you could be enabling a driver that acts as a SCSI host adapter (and requires the SCSI subsystem). That's the exception to watch out for. Especially when an older kernel uses a SCSI block driver, and a newer kernel now uses the statically built ATA.
-
Bryan J. Smith -
Les Mikesell -
Preston Crawford -
Robert Hanson -
Scot L. Harris