GNOME Bugzilla – Bug 539185
Improve knowledge presentation about partitions
Last modified: 2016-10-09 16:06:33 UTC
I want that more knowledge about partition dependencies and constraints will be presented in the user interface to manage their boundaries easier and safer. http://en.wikipedia.org/wiki/Cylinder-head-sector#History http://www.linux.org/docs/ldp/howto/Large-Disk-HOWTO-6.html http://www.partitionsupport.com/partitionnotes.htm http://groups.google.de/group/comp.os.linux.hardware/msg/7b40a6e694085078 - Some operating system instances require that partition start and/or end at a cylinder boundary. - Boot loaders like LILO had limitations. The maximum assignable cylinder number might be 1023 for this tool. The position definitions (storage layout) should be adjusted according to the partition types. It should also be possible that partitions stay unchanged even if their boundaries were intentionally not set at a cylinder boundary. The layout management might become harder if no dynamic policies are available or enforced because a handling "Snap/Round to cylinders" is enabled by default.
What specific changes do you suggest for improving knowledge presentation about partitions?
(In reply to comment #1) I suggest to offer also a task-oriented interface for partition adjustments. If the user can choose and specify the purpose of a specific partition, your tool will be able to consider corresponding constraints.
Is this something that you would be interested in developing?
(In reply to comment #3) Yes - I hope that we would be more interested to achieve improvements in the mentioned software area in cooperation. Which knowledge (constraints ...) is needed and where should the involved facts be stored? ;-)
Perhaps a tool tip for the alignment options would be preferable to a wizard for partition creation? Following are my reasons for suggesting that a tool tip might suffice. Let me start by going back to your original post. (In reply to comment #0) > - Some operating system instances require that partition start and/or end at a > cylinder boundary. As far as I know, this only applies to vintage operating systems (i.e., some that were released prior the year 2000). For instance DOS is an operating system that requires that partitions be aligned to cylinders. Modern operating systems, such as GNU/Linux and Windows 7 do not have these restrictions. In fact from my testing, Windows XP partitions do not need to be aligned to cylinders. A note about alignment is contained in the GParted Manual: http://gparted.sourceforge.net/docs/help-manual/C/gparted.html#gparted-specify-partition-alignment Some of the information in this note would be useful to present to the user, such as in a tool-tip. > - Boot loaders like LILO had limitations. The maximum assignable cylinder > number might be 1023 for this tool. I believe that the 1023 cylinder limitation was due to limitations in the BIOS used on old computers. From the following link, it would appear that modern releases of LILO can use Logical Block Addressing (LBA). http://en.wikipedia.org/wiki/LILO_%28boot_loader%29 Hence the BIOS would appear to be the limiting factor, not LILO. If you know of a way to test for this limitation in the BIOS, then it would be helpful for GParted to be able to inform users of this constraint. Then the following bug report could be re-opened and more appropriately resolved: Bug #625981 As an additional note, the GParted application on the current GParted Live image requires at least 128 MB of RAM to be fully functional (copy and move are memory intensive). This is considerably more memory than was typically used on old computers running DOS. As such current versions of GParted tend to be too resource intensive for such older computers.
(In reply to comment #5) > Perhaps a tool tip for the alignment options would be preferable to a wizard > for partition creation? No, I do not think so. It might help as an intermediate step. I imagine that a complete solution will be different. > As far as I know, this only applies to vintage operating systems (i.e., some > that were released prior the year 2000). Would we like to support (older) systems that contain restrictions? > If you know of a way to test for this limitation in the BIOS, then it would be > helpful for GParted to be able to inform users of this constraint. I am not familiar with this detail level so far. > As an additional note, the GParted application on the current GParted Live > image requires at least 128 MB of RAM to be fully functional (copy and move are > memory intensive). This is considerably more memory than was typically used on > old computers running DOS. As such current versions of GParted tend to be too > resource intensive for such older computers. Can more powerful systems provide partitioning services (including storage movement) for systems with the mentioned low resources?
(In reply to comment #6) > Would we like to support (older) systems that contain restrictions? Yes, we would like to support disk device partitioning on as many systems as is reasonably possible. > Can more powerful systems provide partitioning services (including storage > movement) for systems with the mentioned low resources? Yes, if the hard drive can be removed from the old computer and connected to a more powerful computer. For your information, over the next work or so I will be busy with many things, including the GParted 0.6.3 release. As such, I will not be able to respond quickly to your questions. After the release of GParted 0.6.3 I plan to re-read all of the bug reports you have submitted to date.
s/next work/next week/ :-)
Would you like to consider any constraints like they are mentioned in another article? http://en.wikipedia.org/wiki/Ranish_Partition_Manager#Partitioning
This request requires a champion with time and effort to see it through, and such a champion has not surfaced. Closing this report as NOTABUG to reduce distraction from other bug reports.
(In reply to Curtis Gedak from comment #10) > This request requires a champion with time and effort to see it through, > and such a champion has not surfaced. I find this information interesting to some degree. Did you become "a champion" eventually? > Closing this report as NOTABUG to reduce distraction from other bug reports. I find this kind of feedback inappropriate.
Please refrain from re-opening this bug report.
(In reply to Curtis Gedak from comment #12) * Can further improvements be still achieved when such an issue seems to be "closed"? * Do you prefer a continuation for the current software situation under a new bug number?