GNOME Bugzilla – Bug 643159
Allow byte-size entry for partition management
Last modified: 2012-11-30 21:54:45 UTC
The disk utility provides partial support for RAID management via md, but allows only very coarse-grained control over partition sizes when creating or resizing partitions: A simple slider (come on!). Especially when dealing with RAIDs the user should have *exact* control over partition sizes. Please also see my idea (and two more proposed solutions) at Ubuntu brainstorm: http://brainstorm.ubuntu.com/idea/27097/
For the record, the current GUI allows 1MB granularity when creating a partition. I can't see any usecase for greater granularity. Closing NOTABUG.
When resizing partitions, byte-level granularity is a common necessity when dealing with RAIDs, LVGs, or other schemes where a certain partition size is specified and inflexible. This is definitely a bug. What reason would there be to deny users byte-level granularity, especially considering there are kernel modules that demand it?
(In reply to comment #2) > When resizing partitions, byte-level granularity is a common necessity when > dealing with RAIDs, LVGs, or other schemes where a certain partition size is > specified and inflexible. We don't support RAID or LVM or filesystem resizing (yet) so you'd already be using the command-line in that case. And for the RAID support planned for Disks 3.8, see http://www.youtube.com/watch?v=RHvk9JwZRac we will only support creating RAID on whole disks. Why? Partly to simplify the user interface but, more importantly, because RAID on partitions is typically unwanted due to all the problems that comes with it (varying sizes, alignment etc). > This is definitely a bug. What reason would there be to deny users byte-level > granularity, especially considering there are kernel modules that demand it? There's a couple of reasons - first of all it's much harder to read and assign meaning to "48318382080 bytes" compared to "45000 MB" and we don't have room in the GUI, see http://people.freedesktop.org/~david/gnome-disks-add-partition.png to show both. It's just unnecessary clutter. The other, and more important reason, is more subtle. We want Disks to be a *high level interface* where the user is not burdened with details such as partitioning. For example, insisting on only supporting RAID on whole disks (that are 99.9% of the time the same size anyway) we completely sidestep this problem and it's a much better experience for the user. Sure, there are cases where you need precise control or you want to do stuff that Disks does not support. For those cases the answer is to open a terminal and use fdisk(8), gdisk(8), parted(8), mkfs(8) or whatever. In fact, the reason that Disks is showing you the device file (e.g. "/dev/sdb") is so you can easily do this. You may not agree with this approach - that's fine - but you don't get to say "this is definitely a bug". Because this is very definitely is *not* a bug - it's how it's supposed to work! Hope this clarifies.
(In reply to comment #3) > (In reply to comment #2) > We don't support RAID or LVM or filesystem resizing (yet) so you'd already be > using the command-line in that case. And for the RAID support planned for Disks > 3.8, see > > http://www.youtube.com/watch?v=RHvk9JwZRac > Not supporting resizing is a terrible justification for not allowing people to have the ability to specify size at creation or modification (e.g., adding a drive). > we will only support creating RAID on whole disks. Why? Partly to simplify the > user interface but, more importantly, because RAID on partitions is typically > unwanted due to all the problems that comes with it (varying sizes, alignment > etc). > > > This is definitely a bug. What reason would there be to deny users byte-level > > granularity, especially considering there are kernel modules that demand it? > > it's much harder to read and assign > meaning to "48318382080 bytes" Tell that to my kernel module that *demands* partitions of size 48318382080 (or what-have-you). It may not mean much to you, and perhaps it's not the most meaningful number a person could choose, but it's a *requirement*. And people who are dealing with these numbers are copying & pasting them, not worrying about their meaning, anyway. > compared to "45000 MB" and we don't have room in > the GUI Then change the GUI. It'd be easy to accommodate a field with width >= 12 digits, for goodness's sake. And, again, you can make granularity variable. If the user wants to specify in MiB, let them. But why not B? Or GiB or KiB, for that matter? > > http://people.freedesktop.org/~david/gnome-disks-add-partition.png > > to show both. It's just unnecessary clutter. It might be unnecessary and/or clutter to you. I don't want to debate subjective points. > The other, and more important reason, is more subtle. We want Disks to be a > *high level interface* where the user is not burdened See, you say "the user is not burdened", but what I'm hearing sounds a lot like an attempt to pander. I just don't see a reason why, even in an effort to abstract the utility away to a super high-level interface, you would not want to extend a greater--yet still very reasonable--level of control to the user. > with details such as > partitioning. For example, insisting on only supporting RAID on whole disks > (that are 99.9% of the time the same size anyway) we completely sidestep this > problem and it's a much better experience for the user. Again, for which users? Some users don't want to know about partitioning, ok, but that's no reason to say no one should have control over disk partitioning. Is there such a strong trend to move away from disk partitioning outside the scope of this issue? > Sure, there are cases where you need precise control or you want to do stuff > that Disks does not support. For those cases the answer is to open a terminal > and use fdisk(8), gdisk(8), parted(8), mkfs(8) or whatever. That's one perspective. Another perspective would be to further empower GUI-only users to have more control over their disks, partitions, and file systems. I mean, even optionally: Put it behind an "Advanced" button if you really think people are so inexplicably put-off by details when they're already in a RAID configuration utility. > In fact, the reason > that Disks is showing you the device file (e.g. "/dev/sdb") is so you can > easily do this. That's the reason?! Why even have that, then? Users don't need it, it's a useless clutter, the GUI doesn't have room to spare, command utilities can give you the same info, etc. I don't understand the inconsistent logic here. > You may not agree with this approach - that's fine - but you don't get to say > "this is definitely a bug". Because this is very definitely is *not* a bug - > it's how it's supposed to work! > It most definitely is a bug for me. I'm not comfortable leaving it as "NOTABUG"; it is a bug, but I can leave it as incomplete. That's really what it is: Incomplete functionality, and today I learned that it's intentionally incomplete. > Hope this clarifies. It's not the answer I was expecting, but it does clarify your attitude towards GUIs intentionally--and I would argue unnecessarily--missing functionality. Thanks for taking the time to write!
As part of resolving bug 689362, there's now a combo-box where you can select "bytes", see http://people.freedesktop.org/~david/gnome-disks-create-partition-unit-combobox.png http://git.gnome.org/browse/gnome-disk-utility/commit/?id=81f7bd32056e7479751c2c661c54cfc4b399de72 thus providing the requested feature. Changing resolution to FIXED. This will be available in GNOME 3.8