IDE partitions [WAS: Re: [opensuse] legalities]
On 9/30/07, Richard Creighton
Carlos E. R. wrote: <snip>
That's not quite so now. For instance, the limit on the number of partitions has been decreased from 64 to 16 (less than). That's one of the consequence of "progress" in the linux field.
- -- Cheers, Carlos E. R.
Someone made an ill-advised decision to change the naming scheme of IDE drives to be the same as the new SATA drives to be the same as SCSI. In the process, it inherited the limitations of the SCSI drives. I can't think of a reason for having done it, but it appears to have been done in all the distros. I suspect there will be a great gnashing of teeth when the next release hits the streets and some accomodation will be forthcoming. As one of the beta testers for upcoming 10.3 SuSE, it has already proven 'interesting' and caused me personally no end of frustration. Generally though, Linux's progress has kept pace with the newer hardware without losing sight of its historical past. This is one of the few exceptions so far. I bet that there is NO chance that XP, much less Vista will run on a 386 or a 286... I cranked up 10.2 on a 486DX-2 the other day just to see it run...slow, but it ran :)
Richard
The issue is far deeper than naming conventions. When SATA support was added to the kernel (libata) they leveraged the entire SCSI subsystem due to its quality compared to the IDE subsystem. Then libata got to so good that many (most) of the PATA drivers were re-implemented (by Alan Cox of Redhat) via libata. And then the new implementations got stable enough that the distros decided to move to the libata pata drivers by default. (Fedora was the first to move in the spring.) But, for the foreseeable future you should be able to use the old drivers/ide implementation and get the old functionality (and naming convention). The long term solution is to have libata implement its own full set of infrastructure and no longer fit under the SCSI infrastructure. When that happens the partition limits should be restored to the higher limits. Novell has Tejun Heo supporting libata. He has done 2 major upgrades to it in the last 18 months (new error handling logic for 10.2, PMP support for 10.3, ??? for 11.0). My hope is that his next big project will be the libata infrastructure, but I have not seen anything posted about that yet. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Greg Freemyer wrote:
On 9/30/07, Richard Creighton
wrote: Carlos E. R. wrote:
<snip>
That's not quite so now. For instance, the limit on the number of partitions has been decreased from 64 to 16 (less than). That's one of the consequence of "progress" in the linux field.
- -- Cheers, Carlos E. R.
Someone made an ill-advised decision to change the naming scheme of IDE drives to be the same as the new SATA drives to be the same as SCSI. In the process, it inherited the limitations of the SCSI drives. I can't think of a reason for having done it, but it appears to have been done in all the distros. I suspect there will be a great gnashing of teeth when the next release hits the streets and some accomodation will be forthcoming. As one of the beta testers for upcoming 10.3 SuSE, it has already proven 'interesting' and caused me personally no end of frustration. Generally though, Linux's progress has kept pace with the newer hardware without losing sight of its historical past. This is one of the few exceptions so far. I bet that there is NO chance that XP, much less Vista will run on a 386 or a 286... I cranked up 10.2 on a 486DX-2 the other day just to see it run...slow, but it ran :)
Richard
The issue is far deeper than naming conventions.
When SATA support was added to the kernel (libata) they leveraged the entire SCSI subsystem due to its quality compared to the IDE subsystem.
Then libata got to so good that many (most) of the PATA drivers were re-implemented (by Alan Cox of Redhat) via libata. And then the new implementations got stable enough that the distros decided to move to the libata pata drivers by default. (Fedora was the first to move in the spring.)
But, for the foreseeable future you should be able to use the old drivers/ide implementation and get the old functionality (and naming convention).
The long term solution is to have libata implement its own full set of infrastructure and no longer fit under the SCSI infrastructure. When that happens the partition limits should be restored to the higher limits.
Novell has Tejun Heo supporting libata. He has done 2 major upgrades to it in the last 18 months (new error handling logic for 10.2, PMP support for 10.3, ??? for 11.0).
My hope is that his next big project will be the libata infrastructure, but I have not seen anything posted about that yet.
Greg
Greg, I usually do a lot of <snipping> but your reply deserves to be seen in context and completeness. What you say is quite probably accurate. The problem is that the implementation was made in such a way as to cause unexpected problems. For many people, it probably was uneventful, but a lot of people have mixed IDE and SATA architectures with motherboards that have both types of controllers. These motherboards typically offer the IDE drives to the OS first, then the SATA drives. I had a perfectly good 10.2 installation on my IDE system drive and added SATA drives to the machine for testing the 10.3 beta. I did not know of the unadvertised decision to incorporate IDE into the SATA/SCSI family. Properly and COMPLETELY done, there would have been no problem. Had there been a warning I could have taken precautions but from 9.3 through 10.2 when I have upgraded, I have never needed to worry about such things. Well, the install went fine, the 10.3 beta installed onto the SATA drive, but the IDE drive normally called hdb1 on my system was suddenly renamed sda2 (my cdrom was on the master channel) and the first SATA drive became sdb1 and when grub was written and the MBR was written, guess where it was put....yup, it clobbered my IDE drive. Of course, this was totally unexpected. OBTW, I neglected to tell you, the SATA drives were not just 1 drive, they were 4 200G drives in a MD Raid configuration which also confused the issue, but that is no reason to clobber the IDE MBR or rewrite it's /boot or /boot/grub entries. To this day, if I want to install any version above 10.3 beta 1, I have to unplug the IDE drive until the installation is complete. Also, the YaST repair modules are totally clueless still about the name changes. So, while the motive to migrate is honorable, the decision to do so unilaterally and without proper notice and warning about possible side effects between minor releases I maintain is and was still ill advised. To do so between version 10 and version 11 would have been much more appropriate, but from .2 to .3, that usually signifies relatively minor changes and enhancements and bug fixes and not major changes. Since I can recall, IDE devices have been called HDxx and drivers and software buried pretty deep has expected this for years. To suddenly change this invites trouble, and it happened. I would have simply unplugged the IDE drive if I had expected trouble, but the stability of SuSE upgrades in the past even in beta has never put drives not part of the experiment at risk before and I grew complacent ... my bad, add a bad decision on the development end and a lot of people are going to wonder what happened. The buglist reports bear that out already. I do appreciate the insight of your reply however, thank you. Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard Creighton wrote:
Greg Freemyer wrote:
On 9/30/07, Richard Creighton
wrote: Carlos E. R. wrote:
<snip>
That's not quite so now. For instance, the limit on the number of partitions has been decreased from 64 to 16 (less than). That's one of the consequence of "progress" in the linux field.
- -- Cheers, Carlos E. R.
Someone made an ill-advised decision to change the naming scheme of IDE drives to be the same as the new SATA drives to be the same as SCSI. In the process, it inherited the limitations of the SCSI drives. I can't think of a reason for having done it, but it appears to have been done in all the distros. I suspect there will be a great gnashing of teeth when the next release hits the streets and some accomodation will be forthcoming. As one of the beta testers for upcoming 10.3 SuSE, it has already proven 'interesting' and caused me personally no end of frustration. Generally though, Linux's progress has kept pace with the newer hardware without losing sight of its historical past. This is one of the few exceptions so far. I bet that there is NO chance that XP, much less Vista will run on a 386 or a 286... I cranked up 10.2 on a 486DX-2 the other day just to see it run...slow, but it ran :)
Richard
The issue is far deeper than naming conventions.
When SATA support was added to the kernel (libata) they leveraged the entire SCSI subsystem due to its quality compared to the IDE subsystem.
Then libata got to so good that many (most) of the PATA drivers were re-implemented (by Alan Cox of Redhat) via libata. And then the new implementations got stable enough that the distros decided to move to the libata pata drivers by default. (Fedora was the first to move in the spring.)
But, for the foreseeable future you should be able to use the old drivers/ide implementation and get the old functionality (and naming convention).
The long term solution is to have libata implement its own full set of infrastructure and no longer fit under the SCSI infrastructure. When that happens the partition limits should be restored to the higher limits.
Novell has Tejun Heo supporting libata. He has done 2 major upgrades to it in the last 18 months (new error handling logic for 10.2, PMP support for 10.3, ??? for 11.0).
My hope is that his next big project will be the libata infrastructure, but I have not seen anything posted about that yet.
Greg
Greg, I usually do a lot of <snipping> but your reply deserves to be seen in context and completeness.
What you say is quite probably accurate. The problem is that the implementation was made in such a way as to cause unexpected problems. For many people, it probably was uneventful, but a lot of people have mixed IDE and SATA architectures with motherboards that have both types of controllers. These motherboards typically offer the IDE drives to the OS first, then the SATA drives. I had a perfectly good 10.2 installation on my IDE system drive and added SATA drives to the machine for testing the 10.3 beta. I did not know of the unadvertised decision to incorporate IDE into the SATA/SCSI family. Properly and COMPLETELY done, there would have been no problem. Had there been a warning I could have taken precautions but from 9.3 through 10.2 when I have upgraded, I have never needed to worry about such things. Well, the install went fine, the 10.3 beta installed onto the SATA drive, but the IDE drive normally called hdb1 on my system was suddenly renamed sda2 (my cdrom was on the master channel) and the first SATA drive became sdb1 and when grub was written and the MBR was written, guess where it was put....yup, it clobbered my IDE drive. Of course, this was totally unexpected. OBTW, I neglected to tell you, the SATA drives were not just 1 drive, they were 4 200G drives in a MD Raid configuration which also confused the issue, but that is no reason to clobber the IDE MBR or rewrite it's /boot or /boot/grub entries. To this day, if I want to install any version above 10.3 beta 1, I have to unplug the IDE drive until the installation is complete. Also, the YaST repair modules are totally clueless still about the name changes.
I don't understand - you have full control over where the MBR is installed. By default, it goes on the first drive found. If you want to change that, you are free to do so. I don't understand why you have to unplug the IDE. I have the same setup (well, not RAID but a mix of IDE & SATA) and 10.3 actually installed better than 10.2 on this system. Not sure why you would blame the installation program.
So, while the motive to migrate is honorable, the decision to do so unilaterally and without proper notice and warning about possible side effects between minor releases I maintain is and was still ill advised. To do so between version 10 and version 11 would have been
For one, 10.3 is still in testing. For another, the drive renaming is mentioned in the Release Notes: http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#08
much more appropriate, but from .2 to .3, that usually signifies relatively minor changes and enhancements and bug fixes and not major changes. Since I can recall, IDE devices have been called HDxx and drivers and software buried pretty deep has expected this for years. To suddenly change this invites trouble, and it happened. I would have simply unplugged the IDE drive if I had expected trouble, but the stability of SuSE upgrades in the past even in beta has never put drives not part of the experiment at risk before and I grew complacent ... my bad, add a bad decision on the development end and a lot of people are going to wonder what happened. The buglist reports bear that out already.
I still don't get why the drive renaming is a big deal. I have virtually never had to deal with the actual name of the drive and don't see why I care what it is called. -- Jonathan Arnold (mailto:jdarnold@buddydog.org) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Jonathan Arnold wrote:
Richard Creighton wrote:
Greg Freemyer wrote:
<snip> I don't understand - you have full control over where the MBR is installed. By default, it goes on the first drive found. If you want to change that, you are free to do so. I don't understand why you have to unplug the IDE. I have the same setup (well, not RAID but a mix of IDE & SATA) and 10.3 actually installed better than 10.2 on this system. Not sure why you would blame the installation program.
Not true...the install program writes to the drive presented as the first bootable drive presented by BIOS under normal conditions, which under normal conditions is your IDE drive. My BIOS allows the SATA drive to be presented 1st and the IDE to be presented last which is the option I chose for this installation. When 10.3 renamed my IDE drive to SDA and it was bootable, IT became the drive where the install program wrote the MBR and I had NO CHOICE. FWIW, I had previously installed 10.2 on the SATA in the MD Raid so I had TWO 10.2 installations, one in the IDE drive and one in the 4 drive MD raid SATA array and it worked perfectly and the MBR for the MD Raid was written correctly on the SATA drive and left the IDE drive alone. When I attempted the same thing with the 10.3, the renaming of the IDE drive to SDA apparently occurred after the install of the program files and the GRUB and MBR updates went to the first bootable drive it now found which was, of course, SDA (formerly the IDE drive containing 10.2) and not the SATA drives containing the new 10.3 installation. So, I blame the installation program.
So, while the motive to migrate is honorable, the decision to do so unilaterally and without proper notice and warning about possible side effects between minor releases I maintain is and was still ill advised. To do so between version 10 and version 11 would have been
For one, 10.3 is still in testing. For another, the drive renaming is mentioned in the Release Notes:
http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#08
The release notes are displayed *after* a successful installation is complete. Perhaps they should be displayed BEFORE the installation starts. As to the fact that 10.3 is still in testing....I have beta tested every version since 9.3 and have always had a 2nd drive with my primary installation and a 2nd drive for the beta install. Starting with 10.2, I also had a new system with SATA drives which were used as the 2nd drive and I also experimented with MD Raid installation of 10.3 onto a 1TB MD Raid on those (4) SATA drives with no problems. I simply wasn't expecting with a minor version release, to have my primary IDE partition affected so drastically. If I had, I would have disconnected the IDE drive electrically but previous experience did not dictate that necessity. Had the installation program functioned properly, it still wouldn't have been necessary. As a beta tester, I am willing to risk my machine and data and time to uncover bugs. I uncovered a major one here and it is directly related to the decision to absorb the IDE drives into the SATA/SCSI world without completely thinking through all the ramifications. Another side effect that is affecting more than a few is the fact that IDE drives can be partitioned up to 64 partitions. The limitation as a SDxx drive is now 16. This makes conversion impossible for some people. How are they going to upgrade? Only after great gnashing of teeth has there been any provision for this little oversight. The great unwashed masses aren't going to be so forgiving if SuSE Linux suddenly causes them to lose data and they aren't technically inclined enough to be able to fix it themselves. Oh, that's another thing...the repair program is still badly broken....especially if you have an LVM or MD Raid installation. Seems to me that if you are allowed to install the OS on such a structure and something needs fixing, then the 'fixing' program should at least not break it further. So, I do blame the installation program and as a beta tester, I darned sure uncovered a bug, a big fat one. Richard
much more appropriate, but from .2 to .3, that usually signifies relatively minor changes and enhancements and bug fixes and not major changes. Since I can recall, IDE devices have been called HDxx and drivers and software buried pretty deep has expected this for years. To suddenly change this invites trouble, and it happened. I would have simply unplugged the IDE drive if I had expected trouble, but the stability of SuSE upgrades in the past even in beta has never put drives not part of the experiment at risk before and I grew complacent ... my bad, add a bad decision on the development end and a lot of people are going to wonder what happened. The buglist reports bear that out already.
I still don't get why the drive renaming is a big deal. I have virtually never had to deal with the actual name of the drive and don't see why I care what it is called.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-10-02 at 09:48 -0400, Richard Creighton wrote:
Jonathan Arnold wrote:
For one, 10.3 is still in testing. For another, the drive renaming is mentioned in the Release Notes:
http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#08
The release notes are displayed *after* a successful installation is complete. Perhaps they should be displayed BEFORE the installation starts.
It is no longer in testing, it is final already. There is another point during the installation where you can read the local copy of the release notes, hidden under something else. Can't be more specific, though, I forget where exactly... I think it is on the registration screen.
As a beta tester, I am willing to risk my machine and data and time to uncover bugs. I uncovered a major one here and it is directly related to the decision to absorb the IDE drives into the SATA/SCSI world without completely thinking through all the ramifications. Another side effect that is affecting more than a few is the fact that IDE drives can be partitioned up to 64 partitions. The limitation as a SDxx drive is now 16.
Less than 16, because number 0 is the whole disk, ie 15 numbers. Then, another number is wasted to the extended partition, so the final number of usable partitions is 14.
This makes conversion impossible for some people. How are they going to upgrade?
Exactly my case. When the pata driver gets removed in version 11, I will not be able to install any more.
I still don't get why the drive renaming is a big deal. I have virtually never had to deal with the actual name of the drive and don't see why I care what it is called.
Because it is not just the names that change. That just the unsubmerged part of the iceberg. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHAlAutTMYHG2NR9URArABAJ4oWf0nxfy/czTJiqQeJ8ksQV4dOwCgiXjN oaywGh4WM8zlftQW/CxhqB8= =h8ky -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard Creighton wrote:
Jonathan Arnold wrote:
Richard Creighton wrote:
Greg Freemyer wrote:
<snip> I don't understand - you have full control over where the MBR is installed. By default, it goes on the first drive found. If you want to change that, you are free to do so. I don't understand why you have to unplug the IDE. I have the same setup (well, not RAID but a mix of IDE & SATA) and 10.3 actually installed better than 10.2 on this system. Not sure why you would blame the installation program.
Not true...the install program writes to the drive presented as the first bootable drive presented by BIOS under normal conditions, which under normal conditions is your IDE drive. My BIOS allows the SATA drive to be presented 1st and the IDE to be presented last which is the option I chose for this installation. When 10.3 renamed my IDE drive to SDA and it was bootable, IT became the drive where the install program wrote the MBR and I had NO CHOICE. FWIW, I had previously
At the installation screen, Expert Options tab, the Change... button lists the Booting option. Here you can set up both the Grub menu and where the MBR gets installed.
installed 10.2 on the SATA in the MD Raid so I had TWO 10.2 installations, one in the IDE drive and one in the 4 drive MD raid SATA array and it worked perfectly and the MBR for the MD Raid was written correctly on the SATA drive and left the IDE drive alone. When I attempted the same thing with the 10.3, the renaming of the IDE drive to SDA apparently occurred after the install of the program files and the GRUB and MBR updates went to the first bootable drive it now found which was, of course, SDA (formerly the IDE drive containing 10.2) and not the SATA drives containing the new 10.3 installation. So, I blame the installation program.
So, while the motive to migrate is honorable, the decision to do so unilaterally and without proper notice and warning about possible side effects between minor releases I maintain is and was still ill advised. To do so between version 10 and version 11 would have been
For one, 10.3 is still in testing. For another, the drive renaming is mentioned in the Release Notes:
http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#08
The release notes are displayed *after* a successful installation is complete. Perhaps they should be displayed BEFORE the installation starts.
Big button at the lower left of the installation screens says: Show Release Notes
As to the fact that 10.3 is still in testing....I have beta tested every version since 9.3 and have always had a 2nd drive with my primary installation and a 2nd drive for the beta install. Starting with 10.2, I also had a new system with SATA drives which were used as the 2nd drive and I also experimented with MD Raid installation of 10.3 onto a 1TB MD Raid on those (4) SATA drives with no problems. I simply wasn't expecting with a minor version release, to have my primary IDE partition affected so drastically. If I had, I would have disconnected the IDE drive electrically but previous experience did not dictate that necessity. Had the installation program functioned properly, it still wouldn't have been necessary.
When you are installing a new OS, sharing the drives with an old OS, whether it is a dot upgrade or a brand new Linux, I would think making sure of where it was installing the MBR would be of a primary importance, and "assuming" you know where that is would be a bad idea in any case. -- Jonathan Arnold (mailto:jdarnold@buddydog.org) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
At the installation screen, Expert Options tab, the Change... button lists the Booting option. Here you can set up both the Grub menu and where
Jonathan Arnold wrote: the MBR
gets installed.
When it works, which it didn't, plus it didn't offer to put it where I needed it anyhow ... 2 bugs
The release notes are displayed *after* a successful installation is complete. Perhaps they should be displayed BEFORE the installation
starts.
Big button at the lower left of the installation screens says:
Show Release Notes
Which says nothing about overwriting OS installations on those renamed drives
When you are installing a new OS, sharing the drives with an old OS, whether it is a dot upgrade or a brand new Linux, I would think making sure of where it was installing the MBR would be of a primary importance, and "assuming" you know where that is would be a bad idea in any case.
We seem to have a failure to communicate here. I have repeatedly said that the damage was NOT to as shared drive but to a separate drive that was not supposed to be affected in any way by the installation and in all previous versions had in fact, been immune. The BUG caused the 'sharing' of the drive against my expectations and will. I get the impression that you think I'm stupid or something for deliberately causing 10.3 to overwrite a perfectly good 10.2 installation boot partition. Of course it is a bad idea if you know it is going to happen and the release notes didn't imply anything about that possibility. Renaming meant squat....as long as it was smart enough to keep the old installation separate from the new installation the way previous installation programs had done since 9.3 through 10.2 and probably earlier. It was a BUG that caused the damage, along with poor design implementation. Thank you for your rather myopic viewpoint Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-10-01 at 16:33 -0400, Greg Freemyer wrote:
The issue is far deeper than naming conventions.
Well, it is caused by using just a byte for the minor number in the /dev directory, instead of a word or a longword. Time they changed that!
When SATA support was added to the kernel (libata) they leveraged the entire SCSI subsystem due to its quality compared to the IDE subsystem.
Then libata got to so good that many (most) of the PATA drivers were re-implemented (by Alan Cox of Redhat) via libata. And then the new implementations got stable enough that the distros decided to move to the libata pata drivers by default. (Fedora was the first to move in the spring.)
But, for the foreseeable future you should be able to use the old drivers/ide implementation and get the old functionality (and naming convention).
Yours is a very interesting explanation. However, it seems that opensuse wants to remove the old pata implementation for the next version, ie #11. If that happens before what you explain below happens, me and others will not be able to install suse.
The long term solution is to have libata implement its own full set of infrastructure and no longer fit under the SCSI infrastructure. When that happens the partition limits should be restored to the higher limits.
Novell has Tejun Heo supporting libata. He has done 2 major upgrades to it in the last 18 months (new error handling logic for 10.2, PMP support for 10.3, ??? for 11.0).
My hope is that his next big project will be the libata infrastructure, but I have not seen anything posted about that yet.
I hope you are right and they do that, sooner than later. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHAWxttTMYHG2NR9URAkPJAJ9oC7PxsLw0LZGFspIVLgkcWhRQ0gCeMQhK 44txkV0syOy71jrV7ne9Rt0= =GgYB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 10/1/07, Carlos E. R.
When SATA support was added to the kernel (libata) they leveraged the entire SCSI subsystem due to its quality compared to the IDE subsystem.
Then libata got to so good that many (most) of the PATA drivers were re-implemented (by Alan Cox of Redhat) via libata. And then the new implementations got stable enough that the distros decided to move to the libata pata drivers by default. (Fedora was the first to move in the spring.)
But, for the foreseeable future you should be able to use the old drivers/ide implementation and get the old functionality (and naming convention).
Yours is a very interesting explanation.
However, it seems that opensuse wants to remove the old pata implementation for the next version, ie #11. If that happens before what you explain below happens, me and others will not be able to install suse.
I hope they keep the old drivers/ide system at least one more release. Surprisingly to me the maintainer (and at least one very active bug fix submitter) is still working on them and often when there is a bug fix to the libata pata driver he implements the corresponding fix to the old stuff. Actually they seem to be leveraging each other, such that a new fix in either subsystem is soon replicated in the other. It is the core scsi/libata infrastructure that apparently is superior to the core ide infrastructure. (That may be less true now than when libata first decided to go with scsi infrastructure.) Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Monday 2007-10-01 at 16:33 -0400, Greg Freemyer wrote:
The issue is far deeper than naming conventions.
Well, it is caused by using just a byte for the minor number in the /dev directory, instead of a word or a longword. Time they changed that!
When SATA support was added to the kernel (libata) they leveraged the entire SCSI subsystem due to its quality compared to the IDE subsystem.
Then libata got to so good that many (most) of the PATA drivers were re-implemented (by Alan Cox of Redhat) via libata. And then the new implementations got stable enough that the distros decided to move to the libata pata drivers by default. (Fedora was the first to move in the spring.)
But, for the foreseeable future you should be able to use the old drivers/ide implementation and get the old functionality (and naming convention).
Yours is a very interesting explanation.
However, it seems that opensuse wants to remove the old pata implementation for the next version, ie #11. If that happens before what you explain below happens, me and others will not be able to install suse.
Why not? I'm not clear on why you wouldn't be able to install with the different naming convention. Or am I missing something else? -- Jonathan Arnold (mailto:jdarnold@buddydog.org) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-10-02 at 08:45 -0400, Jonathan Arnold wrote:
However, it seems that opensuse wants to remove the old pata implementation for the next version, ie #11. If that happens before what you explain below happens, me and others will not be able to install suse.
Why not? I'm not clear on why you wouldn't be able to install with the different naming convention. Or am I missing something else?
That named convention, as you call it, is limited to 15 partitions. Actually, 14, if you discount the extended partition. And I have 20. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHAk3StTMYHG2NR9URAijoAJ4qiCqgxVGNo9llsKKg8TG7XzodmwCdFNva nQ93Svees7C2dNUFY54OEYs= =lEjK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Tuesday 2007-10-02 at 08:45 -0400, Jonathan Arnold wrote:
However, it seems that opensuse wants to remove the old pata implementation for the next version, ie #11. If that happens before what you explain below happens, me and others will not be able to install suse.
Why not? I'm not clear on why you wouldn't be able to install with the different naming convention. Or am I missing something else?
That named convention, as you call it, is limited to 15 partitions. Actually, 14, if you discount the extended partition.
And I have 20.
Ah, okay. The Release Notes now offer two workarounds for this problem and I'd be pretty optimistic that an even better solution would be offered for this by the time 11 rolls around. Although you have to admit, "limited" to 15 partitions isn't something very many people would run into. -- Jonathan Arnold (mailto:jdarnold@buddydog.org) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2007/10/02 12:43 (GMT-0400) Jonathan Arnold apparently typed:
Although you have to admit, "limited" to 15 partitions isn't something very many people would run into.
I won't admit, but it depends on the definition of "very many". If you search seriously, you'll find enough hits to see the problem is not insignificant. A starting point: http://www.google.com/search?num=20&hl=en&safe=off&q=libata+%2215+partitions%22&btnG=Search -- "The basis of our Bill of Rights comes from the teachings we get from Exodus and St. Matthew, from Isaiah and St. Paul. President Harry S. Truman Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-10-02 at 12:43 -0400, Jonathan Arnold wrote:
That named convention, as you call it, is limited to 15 partitions. Actually, 14, if you discount the extended partition.
And I have 20.
Ah, okay. The Release Notes now offer two workarounds for this problem and I'd be pretty optimistic that an even better solution would be offered for this by the time 11 rolls around. Although you have to admit, "limited" to 15 partitions isn't something very many people would run into.
The workaround did not work till RC1, by the way. As for the better solution to arrive in time, I'm not optimistic, as it has to come from the kernel chaps or nearby. And as to 15 partitions being enough... depends for whom. With the current size of disks being in the half a tera byte range, that's becoming easier. And for people having several operating systems and / or test partitions, 15 is not enough - more so as it is a regression from the previous 63. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHAqsltTMYHG2NR9URAm72AJsH5oQ9ElM3FV3NecjZ6wYvOp1GgwCfVPR3 zWqV4QqFaIOcQzxO1c5pMMQ= =IjI8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Jonathan Arnold wrote:
Ah, okay. The Release Notes now offer two workarounds for this problem and I'd be pretty optimistic that an even better solution would be offered for this by the time 11 rolls around. Although you have to admit, "limited" to 15 partitions isn't something very many people would run into.
I would have to agree - maybe someone who's playing around with all sorts will have a need for that many partitions, but for an every day working environment, I use no more than three. /Per Jessen, Zürich -- http://www.spamchek.com/ - your spam is our business. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 09 October 2007 08:46, Per Jessen wrote:
Jonathan Arnold wrote:
Ah, okay. The Release Notes now offer two workarounds for this problem and I'd be pretty optimistic that an even better solution would be offered for this by the time 11 rolls around. Although you have to admit, "limited" to 15 partitions isn't something very many people would run into.
I would have to agree - maybe someone who's playing around with all sorts will have a need for that many partitions, but for an every day working environment, I use no more than three.
HiPer, Welllll....with these new huge discs, it can be a problem. I run three distros on one drive. I like to make /home /tmp /var & /usr separate. Include the primary / and you have used 15 partitions. Include one swap for all of them and you now have used 16. Actually /swap is on another drive. I still have about 80GB left on that disc and not enough partitions to use it if I continue with my current thinking. What are the three that you use? Are you not afraid of running out of space in the partitions which can grow so fast? Yes, I know, could use LVM but that frightens me when all of the partitions for the different distros are thrown together in one big pool. Maybe I don't understand it well enough so I avoid it. Anyway, 10.3 is an absolute delight. Works great, seems to be really fast. A few small niggling problems like 3D rendering but nothing that cannot be overcome. Bob S. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-10-10 at 01:23 -0400, Bob S wrote:
I would have to agree - maybe someone who's playing around with all sorts will have a need for that many partitions, but for an every day working environment, I use no more than three.
Welllll....with these new huge discs, it can be a problem. I run three distros on one drive. I like to make /home /tmp /var & /usr separate. Include the primary / and you have used 15 partitions. Include one swap for all of them and you now have used 16. Actually /swap is on another drive. I still have
Exactly. And /boot, and windows, etc. Then, you could dedicate partitions to certain programs to block them if the go berserk from claiming the entire disk. Traditionally, databases were given their own partition. I have one for vmware. Also, you can have other partitions for replication backup. There are many uses for as many partitions as you like. It's simply a different strategy from the one for all. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHDJTatTMYHG2NR9URAn78AJ4ml1Wn3yvYIlKQMLwTsgXOH3mp/QCeLbGg 2zGnj5bFv2pVGaHUQTscwx4= =Q3VF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Bob S wrote:
On Tuesday 09 October 2007 08:46, Per Jessen wrote:
Jonathan Arnold wrote:
Ah, okay. The Release Notes now offer two workarounds for this problem and I'd be pretty optimistic that an even better solution would be offered for this by the time 11 rolls around. Although you have to admit, "limited" to 15 partitions isn't something very many people would run into. I would have to agree - maybe someone who's playing around with all sorts will have a need for that many partitions, but for an every day working environment, I use no more than three.
HiPer,
Welllll....with these new huge discs, it can be a problem. I run three distros on one drive. I like to make /home /tmp /var & /usr separate. Include the primary / and you have used 15 partitions. Include one swap for all of them and you now have used 16. Actually /swap is on another drive. I still have about 80GB left on that disc and not enough partitions to use it if I continue with my current thinking. What are the three that you use? Are you not afraid of running out of space in the partitions which can grow so fast?
But why do you need separate partitions for all of those? All it adds is complexity, unless you live and breathe 'dd', which is most comfortable with partitions. You would have separate partitions if you wanted to share the /home folder, for instance, but not if they are completely isolated. Just put them all in / and be done with it, I say. And why not share the swap partition? Nothing special goes in there. I'm an OS junkie too, but four partitions per hard drive work fine. -- Jonathan Arnold (mailto:jdarnold@buddydog.org) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-10-10 at 10:24 -0400, Jonathan Arnold wrote:
on one drive. I like to make /home /tmp /var & /usr separate. Include the primary / and you have used 15 partitions. Include one swap for all of them and you now have used 16. Actually /swap is on another drive. I still have about 80GB left on that disc and not enough partitions to use it if I continue with my current thinking. What are the three that you use? Are you not afraid of running out of space in the partitions which can grow so fast?
But why do you need separate partitions for all of those? All it adds is complexity, unless you live and breathe 'dd', which is most comfortable with partitions. You would have separate partitions if you wanted to share the /home folder, for instance, but not if they are completely isolated. Just put them all in / and be done with it, I say.
I don't see why we should put everything in /.
And why not share the swap partition? Nothing special goes in there.
I'm an OS junkie too, but four partitions per hard drive work fine.
How do you install half a dozen OSes in the same disk, without doing partitions? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHDOditTMYHG2NR9URAgLsAJsHTk3JmWKQz2IZVzpgZVqg6OVZxwCeKSzt IYkyh/wrQld8e9QOqQiCLYI= =Dmln -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Wednesday 2007-10-10 at 10:24 -0400, Jonathan Arnold wrote:
on one drive. I like to make /home /tmp /var & /usr separate. Include the primary / and you have used 15 partitions. Include one swap for all of them and you now have used 16. Actually /swap is on another drive. I still have about 80GB left on that disc and not enough partitions to use it if I continue with my current thinking. What are the three that you use? Are you not afraid of running out of space in the partitions which can grow so fast?
But why do you need separate partitions for all of those? All it adds is complexity, unless you live and breathe 'dd', which is most comfortable with partitions. You would have separate partitions if you wanted to share the /home folder, for instance, but not if they are completely isolated. Just put them all in / and be done with it, I say.
I don't see why we should put everything in /.
Not saying you should, just wondering why you wouldn't. Seems to be much less complicated that way.
And why not share the swap partition? Nothing special goes in there.
I'm an OS junkie too, but four partitions per hard drive work fine.
How do you install half a dozen OSes in the same disk, without doing partitions?
Well, I stick with four myself, but as I have 3 drives, each can have 4 of them. -- Jonathan Arnold (mailto:jdarnold@buddydog.org) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-10-11 at 14:18 -0400, Jonathan Arnold wrote:
I don't see why we should put everything in /.
Not saying you should, just wondering why you wouldn't. Seems to be much less complicated that way.
There are advantages. As the saying goes, there are many ways to skin a cat; loosing one of them is not good. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHDp6JtTMYHG2NR9URAg/VAJ95xnemrAnyShJ8h1zY421sPqIJ+wCdF4R9 vZX8Z+qEKPb4JxBXCs6Y/Fc= =cRuH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Oct 9 2007 14:46, Per Jessen wrote:
Ah, okay. The Release Notes now offer two workarounds for this problem and I'd be pretty optimistic that an even better solution would be offered for this by the time 11 rolls around. Although you have to admit, "limited" to 15 partitions isn't something very many people would run into.
See http://lkml.org/lkml/2007/10/5/76 Basically their stance is to use kpartx. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-10-10 at 11:54 +0200, Jan Engelhardt wrote:
See http://lkml.org/lkml/2007/10/5/76 Basically their stance is to use kpartx.
Too technical for me, I don't understand the code. No idea what kpartx is. - From reading that thread, I see that there is no clear solution provided. For instance, some propose using the available 20 bit minors, but this solution was vetoed. And I don't feel safe about using a userspace solution, either... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHDKowtTMYHG2NR9URAk62AJ9tY2bv0oq/IdIdcuCmR4MeG3HIOACaAsBc jvjY17D70x+ZTIK9AkfuUx8= =djyR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
Bob S
-
Carlos E. R.
-
Felix Miata
-
Greg Freemyer
-
Jan Engelhardt
-
Jonathan Arnold
-
Per Jessen
-
Richard Creighton