I ran PartitionMagic through a series of tests on my system. I have a SCSI-based computer using a Symbios 53c860-based SCSI host adapter with a secondary adapter based on the Initio 9100UW chip. I ran tests with my SCSI hard disks attached to each of these adapters, with similar results both times. My hard disks include a 4GB Micropolis UltraSCSI, a 2GB Micropolis Fast SCSI-2 and a 2GB IBM UltraSCSI. Since one of the 2GB drives was used entirely for Linux swap space and temporary storage for CD-ROM creation, I was able to use it as a test-bed drive, copying file systems from the other two drives and modifying them with impunity. Most of my tests involved copying, moving and resizing EXT2 and HPFS partitions, although I also tried some operations on FAT-16 and FAT-32 partitions.
In operation, PartitionMagic 4.0 was relatively easy to use and worked as advertised—some of the time. Unfortunately, it produced errors of one sort or another on my system at least as often as it functioned correctly. Sometimes the errors would appear at the end of an operation and not have any apparent ill effect. A few times they would appear at the beginning of an operation, causing it to abort. Other times, particularly with copy operations, errors would occur at the end of an operation and abort it. I also encountered file system corruption on some tests, particularly tests involving HPFS. The one time I encountered ext2fs corruption, e2fsck was able to correct the problems.
For a number of reasons, I am certain that my physical hard drive system is not to blame for these problems. First, I did a low-level format on the IBM drive I was using as a test bed, so I am certain it was free from physical defects. Second, PartitionMagic 4.0 reported no errors on the drive when it was configured to check for them prior to each operation. Third, problems occurred on both the IBM and the Micropolis 2GB when I reconfigured my system to use it for the tests. Fourth, problems occurred with both the Symbios 53c860 board and the Initio board as the host for the hard disks. Finally, problems did not occur when I tried the same operations with PartitionMagic 2.02 (when they were possible with that version of the program).
Thus, I am quite certain that PartitionMagic 4.0 has some serious bugs. These bugs are so severe and so obvious that I find it hard to believe a reputable company would ship a product knowing these bugs existed. Therefore, I must conclude that PowerQuest did not know they existed (although I have now filed extensive bug reports with them) and that something about my system was turning up bugs in the software. Perhaps the peculiar drive geometry on my first physical disk (1018 cylinders, 133 heads, 62 cylinders), produced by the Symbios host adapter, has something to do with it; or maybe PowerQuest simply did minimal testing with SCSI systems; or perhaps their testing used relatively simple partitioning. My drives each have at least two partitions and problems tended to turn up more frequently with three or more partitions.
In addition to the out-and-out primary function bugs, Partition Magic has a number of limitations, some of which would not even occur to many people except that the program really can do so much. Specifically:
The Boot Magic program had problems booting a FreeBSD partition on my system.
The program has problems with some Linux-created partition tables. Specifically, and according to the PartitionMagic documentation, Linux's fdisk creates extended partitions with logical partitions listed in order of creation, which may not be the same as the order of the partitions themselves (e.g., sda6 may appear before sda5). PartitionMagic 4.0 will choke on such partition tables, though version 2.02 doesn't seem to have any problem with them.
There appears to be no way to merge the contents of two partitions; if you have, say, /usr and /usr/X11R6 on two partitions on one drive, you can't turn them into one partition from within PartitionMagic (although you can increase the size of /usr, reboot to Linux, copy /usr/X11R6 to the enlarged /usr, reboot to PartitionMagic, delete /usr/X11R6 and increase the size of /usr again).
Re-sizing or moving a Linux boot partition will render the partition unbootable (assuming LILO is being used to load a kernel image off that partition). Linux users would do well to ensure that they have a floppy with a kernel image, and also a full-fledged Linux boot system with a text editor to handle any necessary changes in /etc/fstab after moving, adding or deleting partitions.
The batch nature of the operations can result in some truly brainless series of operations. If you enter a partition resize operation, then decide you want to perform a different resize on the same partition, both will most likely be executed, although one would do. Fortunately, you can clear the entire queue of changes; however, you can't delete a single operation.
|Comprehensive Identity Management and Audit for Red Hat Enterprise Linux||Jun 29, 2015|
|Linux Kernel 4.1 Released||Jun 26, 2015|
|Secure Server Deployments in Hostile Territory||Jun 25, 2015|
|Take Control of Growing Redis NoSQL Server Clusters||Jun 24, 2015|
|Django Templates||Jun 24, 2015|
|Attack of the Drones||Jun 23, 2015|
- Comprehensive Identity Management and Audit for Red Hat Enterprise Linux
- Secure Server Deployments in Hostile Territory
- Linux Kernel 4.1 Released
- Django Templates
- Cinnamon 2.6 Released
- Gettin' Sticky with It
- Attack of the Drones
- Take Control of Growing Redis NoSQL Server Clusters
- diff -u: What's New in Kernel Development
- Physics Analysis Workstation