New In KDE Partition Manager 1.1 (V): Options Galore
There is without a doubt something to be said in favour of applications that cannot be configured: If they work more or less exactly the way the user wants them to they are simply perfect. Now, KDE Partition Manager 1.0 was maybe not quite perfect -- but at least it could not be configured in any way.
Anyway, this is about to change with KDE Partition Manager 1.1: The new version comes with a fantastic new two-page configuration dialog. The first page is for general settings and looks like this:
In the following I will quickly go through all of these settings:
Permissions
Allow applying operations without adminstrator privileges: If this is ticked, KDE Partition Manager will let you apply operations in the main window even when you are not running it as root.
Please note that, depending on what operations you perform, this might or might not work: If your user has access rights to a disk device node, like "/dev/sda" for instance, that you manipulate, operations will generally succeed, but KDE Partition Manager will not be able to let the Linux kernel know about changes you made to the partition table itself --because the kernel only accepts the request to re-read partition tables from the root user.
So what is very likely to happen sooner or later is this: You create a new partition, set it to have, e.g., an ext4 file system, and click apply. KDE Partition Manager will create the partition and then try to inform the kernel about the change. The kernel will not accept this request and ignore the new partition. KDE Partition Manager will then abort applying operations with an error, but still show the new partition (albeit with an unknown file system) after rescanning devices, leaving you puzzled.
Note that even if you now try to create a file system it will still fail: The file system create command cannot find the device, only KDE Partition Manager itself can.
This is one example where applying operations as a non-root user is guaranteed not to work. Other operations are not as tricky. Creating a different file system on an existing partition, for example, will work as long as your user has access rights to the device node.
Bottom line: Don't use this option unless you have a very good reason to do so. And expect operations failing once you activate it. But on the other hand, there is also no scenerario I can think of where this would lead to data loss -- it is just confusing and irritating.
Partition Alignment
We have heard all about partition alignment in an earlier installment of this series. If you've missed it (or skipped it because it was long, technical and seemed boring), go back and read it now or never buy a new hard disk again: Correctly aligning partitions is important.
With Align partitions per default you set if the "Align partition" checkbox in the new dialogs dealing with partition sizes is checked per default or not. Unless you have a good reason to turn this off it is better left on: In case you've not heard of it -- correctly aligning partitions is important.
The next checkbox, Use cylinder based alignment (Windows XP compatible), sets which alignment scheme is to be used per default. Note that each disk will still be heuristically scanned for the partitioning scheme in use when scanning devices, so this is is ultimately just the default setting for new and empty devices.
Finally, the Sector alignment spinbox sets how partitions are aligned when using the new 4KiB-physical-sector compatible alignment scheme. The deafult of 2048 sectors is what Microsoft Windows Vista and Windows 7 use and is a sensible value in most cases.
Logging
The Hide messages below combo box determines what the minimum log level is for a message to appear in the log output pane.
File Systems
The Default file system combo box lets you decide which file system is set per default in the dialog when creating a new partition. It is of course just the preselected value in the combo box that still can be changed.
Backend
KDE Partition Manager 1.1 can make use of different backend plugins to do all the dirty work behind the scenes. With the combo box Active backend you can set which backend is currently in use. It is possible to change backends on the fly, but you will lose your list of currently pending operations if you change it.
On a default install there will only be the LibParted backend available for now.
Shredding
Another new feature in KDE Partition Manager 1.1 is the ability to "shred" partitions when deleting them. Unlike when just deleting a partition (which basically means its entry in the partition table is deleted but the data remains on disk for the time being, until it is eventually overwritten with something else) this will actually overwrite the data before the partition is removed from the partition table.
Obviously this is useful if the partition contained data the user wants to be definitely deleted for good, be it for security or any other reasons.
The Overwrite with radio buttons set whether the partition is overwritten with zeros (which takes some time but is relatively fast) or with random data (which can take a very very long time, but is supposedly more secure).
The second configure page deals with file system colors and looks like this:
What you can do here is set a color for each file system KDE Partition Manager 1.1 supports. These colors will then be used in all graphical represenations of devices and partitions and in the main windows's partition list.
This concludes part five in a sequence of entries presenting some of the new features of the soon-to-be-finished KDE Partition Manager 1.1. Part one was about Mount Management, part two dealt with SMART Status Reports, part three offered a very technical look behind the scenes on the topic of Support For 4096-Byte Sectors and part four introduced the Improved Size Dialog.
19 Comments
It is nice that KDE SC gets own partition manager.
Is it really necessary to have groups for every option? For me it looks like it would be better if groups in that UI would be removed and only show all the options nicely.
And is it wise at all to allow option to manage partitions without root (please, lets use the old and familiar and original root and not "administrator") rights?
I've used many partitioning and filesystem tools over the years (from DOS 6 in the early 90s) and am generally equally comfortable with graphical, semigraphical (cfdisk) and CLI based tools. Currently I use gdisk, for GPT based partitions, on everything from thumb drives to external hard drives to md/RAID volumes to the partitions on the physical drives containing those md/RAIDs.
But I've been following kde partitionmanager for some time, and in particular have enjoyed this series of blog posts. While I'm perfectly at home on the command line, not everybody is, and partitionmanager should be a good tool for installers and emergency recovery disks.
So keep up the good work. =:^)
And umm... maybe, someday, I can look forward to having md/RAID partition management, complete with nesting, etc, all visualized in there as well? =:^) Eh, maybe not, but you're already handling the filesystems, which could be argued to be similarly out of scope, and proper btrfs support will mean logical support for its internal raid, etc, already, so md/RAID and device-mapping/lvm2 support isn't /that/ far removed from proper btrfs support, which you'll pretty much have to have once it goes mainline default, to continue proper filesystem support anyway, so maybe md/RAID support isn't that far off after all. =:^)
Anyway, a couple labeling niggles here:
1) I sort of agree with Fri13 on the admin/root thing, altho that's pretty much what I'd think would be best, admin/root or administrator/root, given the likely audience inclusion of folks dual booting other than *ix.
2) The sector alignment setting is confusing, as it has no units label. Intuitively, I'd read that as 2048 bytes, not the least because it's a simple multiple of 1024, and thus read it as an alignment of 2048 bytes, not 2048 sectors. Knowing about 4096-byte physical sectors, I'd be almost certain to increase it to that on such hardware, and probably something well above that, maybe even 1048576, the default MS platform bytes, again, thinking it was in bytes, and ending up with 512 times that, half-gibibyte alignment! So please be sure to at /least/ have a units label. But that also leads to...
3) Choosing units of sectors is bound to be confusing as the sector size changes. Will that config mean 2048 512-byte sectors on old disks and 2048 4096-byte sectors on upcoming disks, with full 4096-byte sectors both logical and physical? What about the intermediate ones with 512-byte logical and 4096-byte physical sectors? Which does it use there?
So I'd strongly recommend that the alignment units be bytes, and that the config widget be labeled as such, to avoid any confusion, and make the resolution 512-byte increments, possibly with a note to the effect that on devices with 4096-byte physical /and/ logical sectors, it'll be rounded to the nearest 4096-byte increment.
Are there any plans to use KAuth for the operations that require root permissions instead of requiring users to run the entire application as root?
@Kevin: There was a short exchange about that in the comment thread for part 4.
I've read this series and I'm very happy about several things.
First and foremost that there's going to be a graphical tool in KDE for this kind of work (adding Duncan's wishes about LVM, etc. would be even cooler, but this ist already absolutely great). And also that you're telling us about the decisions you made about the different parts of this puzzle.
I acutally only have some reservations about the options, that are currently exposed. Not because there are options, but because some of them seem... dangerous in the hands of uninformed users.
How is your approach on educating those users? They probably never read your blog, so, do you include the necessary information on the choice about alignment or not (negative effects in case of non-alignment with modern drives) in tooltips/help/etc.? I guess you will, but this is the sole information that was missing in this blog-series. ;)
Especially this new options-dialog is able to cause much irritation. I'm always thinking about users like my father that keep doing stuff they know nothing about without stopping and learning first. :D
Frankly, I'd be for removing the backend and permissions options as I can't see any benefit, but users changing then and then filing bug reports or abandoning the program since it "doesn't work."
Are there any use cases?
It's pretty cool to see development of a KDE partition manager!
A few suggestions for the options:
- perhaps some options can be moved to a second tab?
(notably the backend and schredding features. They are advanced options)
- is the color configuration really necessary?
If I couldn't change it, I would probably be fine with it as well.
Otherwise it can probably be better changed to one color-scheme pulldown field. :-)
Thanks for this long comment, Duncan. It's great to get such detailed feedback.
The alignment spinbox indeed needs a unit suffixed. Fixed that.
Regarding using bytes (or rather KiB or MiB in this case) as unit instead of sectors I can see the benefits of doing that and also potential downsides of the current approach -- I'll think about it again.
It would require to convert from bytes to sectors using physical sector size, not logical. There currently is no way that I know of to do that easily (without signigicantly changing the application's library dependencies).
I'll look into it.
Thanks for the kind words, Jan.
You're correct, that's a problem I haven't spend enough time thinking about yet.
I had started out with a general and an advanced tab, but merged the two tabs into one because there were so few options. Maybe I'll move the backend combo and the non-admin checkbox to an advanced tab again. And I might even hide that advanced tab per default and only show it if a command line switch is present. I'll have to think about it and try out what works best.
KDE Partition Manager has a very verbose and comprehensive handbook, currently not available from the Help Menu for technical reasons (it is available on docs.kde.org. This is about to change with 1.1 as well thus the manual will be right there under the (uneducated) user's nose. Now we all know that users don't like reading manuals, but what more can you do?
Moving away (or even removing) the non-root-option and the backend-option is something worth thinking about as it's hard to argue there are valid use cases. Removing the sector alignment option just because someone might use it wrongly? I don't know.
As I said in my reply to Jan's comment above I tend to agree on with you on this. I'll probably move those to an advanced tab at least.
In version 1.0 the app did not have options so I'm maybe under-estimating the general user's inclination to use them in a wrong way...
Thanks Diederik.
See me replies to the other comments for my stance on an advanced tab: I'm all for it!
I don't think the color configuration can do any harm. Also, in comments to an earlier installment people complained they did not like the current colors.
Great work also, it's good to have an alternative to gparted and beyond.
But I have to agree with some comments: I think there is such a thing as too many options, and the color config is such an example. Have you talked to the usability guys about this?
I completely agree on the general point: Having too many options in an app is harmful.
However, I don't really see the point here. You cannot cause any damage with the color config. And it does not get in your way.
You don't see it unless you specifically request to see it.
What usability objections could there be, taking into account there are two (three, counting the new advanced tab I just committed) categories in the dialog?
Nice work!
I just don't get one point:
The label for alignment on cyclinders says "Windows XP compatible" - but in one of the last blog posts you wrote:
"Microsoft’s Windows XP still uses this scheme, but can read and deal with partition tables that are laid out differently."
So why bother mentioning "Windows XP" there when it supports non-cylinder aligned partitions just fine? It will confuse users (when I first saw this I thought that this is abolutely needed if I want to mount the partition from Windows XP)
Oh, just had another idea for improvement:
I'd group options differently together.
How about moving Alignment, File System and maybe also Schredding into a tab labeled such as "Partition Handling"?
This will make the general tab less crowded
When I wrote about the usability, I was thinking also about the colors themselves -- there might be some ideas on how to generate a better set of default colors, or reuse a smaller set of colors instead of having a unique color per fs suported, because in reality no-one is going to have more than 3 or so different filesystems.
I still don't see the usecase where someone uses a partition manager so frequently, or just stares at it so much that they say "I wish there was a config dialog where I could change those colors".
Following comments by Fri13, Duncan & mutlu on the 'Allow applying operations without adminstrator privileges' option: I would really think this should at least be severely hidden. Frankly I think tinkering with partitions and file systems is so fundamental that it should only be allowed to those with root permissions. Just recalling a few embarrassing moments from my early DOS/Windows days...
Having said that: these series of blogs are fan- & funtastic, vlanz! You might use parts of it to address Jan's request to educate users. Had I had such education when I jumped to fdisk, a long long time ago!
Well, I'm still thinking of "verbose" tooltips. They could say something like "Attention, possible problems ahead, please read handbook carefully before changing this".
But I also know that too many of these messages are ignored by exactly those users for whom they are written...
That had me worried too, Martin, but then I realized that the option isn't talking about actually allowing actions, but rather, allowing the app to try them.
IOW, if the device permissions are set properly, partition manager running as a user isn't going to be able to change anything, regardless of how that option is set, because all they'd get is a permission error if they tried. Rather, the partition manager option simply configures whether the it has the features enabled in the GUI, or whether they're dimmed out, when run as an ordinary user. It's not like the user can do anything with the partitions using partition manager that he couldn't do otherwise, using whatever other tools, or even a simple dd, directly to the device, if the permissions allow it in the first place.