Dual Boot with 2 HDD

Corin · 08-09-2003, 09:52 AM

Quote:

i haven't read the multi-boot HOWTO

Informed advice is always better than uninformed speculation.

Quote:

your hardrives are on the same IDE channel

For optimum performance and longer life, one uses SCSI disks and not IDE disks.

If you had read the Multi-Disk-Howto or other articles on this matter you would indeed know that for the sake of performace you never put more than one disk (or preferably more than one device) on an IDE controller.

At the end of the day, it's your system and your machine.

One can run it in whatever configuration one wishes, even if it is the one which gives poorest performance. But that is one's right and one's choice, which must be respected.

synaptical · 08-09-2003, 10:56 AM

Quote:

Originally posted by Corin
Informed advice is always better than uninformed speculation.

i agree, which is why i was raising the issue to ask.

Quote:

If you had read the Multi-Disk-Howto or other articles on this matter you would indeed know that for the sake of performace you never put more than one disk (or preferably more than one device) on an IDE controller.

At the end of the day, it's your system and your machine.

One can run it in whatever configuration one wishes, even if it is the one which gives poorest performance. But that is one's right and one's choice, which must be respected.

as a newbie to linux, i simply found it impossible to read all the documentation in one day.

i do have an advanced degree in technical writing (M.S.), on top of an undergraduate degree in English, but even then, the poor, outmoded style of typical linux documentation -- not to mention the sheer volume -- made that impossible, sorry. i did try.

actually, i am not displeased with the performance of my linux drive as slave to master HD on single IDE channel at all. at over 581 MB/sec cache read and 57 MB/sec disk read, it's one of the highest hdparm scores i've ever seen for an IDE drive. i must be doing something right!

but thanks for the pointers.

Corin · 08-09-2003, 03:19 PM

Quote:

Originally posted by synaptical
the poor, outmoded style of typical linux documentation -- not to mention the sheer volume

I have to agree with you that much of the information in the HOWTOs is written in a style which seems to assume expert level knowledge of the area, since it is usually written by the expert of that topic.

And sheer volume as you say is also an issue.

What I find myself doing with the HOWTOs is not sitting down and reading from start to finish (which does pose some dangers) but going to the relevant section and trying to glean some understanding from the examples given.

Quote:

i must be doing something right!

but thanks for the pointers.

Yes, and the reason is because you have gone to the trouble of learning how to use hdparm to tune your disks for the best performance. But the plain fact remains that by keeping to one drive per controller you are not going to run into the master/slave limitation performance issue. Furthermore, if one decides to do software raid, it is even more critical to keep away from more than one device per controller.

To quote from the Software-RAID-HOWTO

Quote:

Also, you should only have one device per IDE bus. Running disks as master/slave is horrible for performance. IDE is really bad at accessing more that one drive per bus.

...

o Only use one IDE drive per IDE bus, slave disks spoil performance

And specifically for RAID

Quote:

It is very important, that you only use one IDE disk per IDE bus. Not only would two disks ruin the performance, but the failure of a disk often guarantees the failure of the bus, and therefore the failure of all disks on that bus. In a fault-tolerant RAID setup (RAID levels 1,4,5), the failure of one disk can be handled, but the failure of two disks (the two disks on the bus that fails due to the failure of the one disk) will render the array unusable. Also, when the master drive on a bus fails, the slave or the IDE controller may get awfully confused. One bus, one drive, that's the rule.