Disks improvements in GNOME 3.6

Just a short exposition of new features and changes in the Disks and udisks releases that will ship with GNOME 3.6

• There are now configuration dialogs for power management for ATA disks, see these two screenshots. Implementation-wise, it's backed by udisks configuration files, see the udisks man page for details. In the future we may add more disk and block device settings (for example, for controlling write-back/write-thru caching)
• The Disks application will now show a Zzz icon if a disk is in standby mode. It looks like this. You can also manually put a disk into standby mode and also wake it up
• There is now a way to erase a disk by filling it with zeroes. If the disk supports the ATA SECURE ERASE command (all modern ATA hard disks from the last decade or so), we support that as well. The erase type is selected from a combo box. In the erase confirmation dialog we also now offer guidance for all three cases since each of them have interesting implications (quick format, overwrite, ATA secure erase). The link in the last warning points the user to the ATA Secure Erase page on the Linux ATA Wiki. Hopefully this guidance is useful for people donating/selling old disks/devices (e.g. remind them to wipe)
• Long-running jobs are now displayed in the Disks user interface along with a way to cancel the job as well
• There's a new "Disk Image Mounter" application for attaching (you've guessed it), disk images. It comes with MIME type associations and in Fedora 18 it is the default application for ISO files. This means that if you double click an ISO file in Files, this application is invoked and it simply just sets up the loop device.
• Combined with this GVfs change the desktop bits will Do The Right Thing(tm) when the user sets up a loop device (don't worry, we don't do anything automatic if your shell script calls losetup(8) - it only affect loop devices set up via the udisks D-Bus interface). For example, if the image contains an installable OS, the desktop will go on to prompt the user to install the OS in the disk image. Note that the machinery is exactly the same as for physical media / devices - e.g. it works with partitioned disk images, the user is prompted to unlock LUKS volumes in the disk image etc. For example, for a ISO image of a Video DVD, the desktop will suggest opening whatever app is registered for x-content/video-dvd (normally Totem but could also be a 3rd party DVD player claiming to support that MIME type)
• The GVfs bits will also toggle the autoclear flag for the loop device when it mounts / unlocks the loop device (or a partition on the loop device) - this is so the disk image is detached when the last user stops using it. This flag can also be toggled from the Disks application, see this screenshot
• After a good and healthy discussion, the desktop shell now offers to save the LUKS passphrases in the keyring again (removed in 3.4, back in 3.6!). So it was a natural thing to make the Disks application read it when unlocking the volume
• Speaking of passphrases, Disks is now using libpwquality and GtkLevelBar. It looks like this
• By popular demand, the benchmark feature that was lost in the Disks/udisks rewrite that landed in GNOME 3.4 is now back - it now looks like this. Not only is it back, it's back in style: write benchmarks are now non-destructive (just use ECC memory, please) and the graph is updated while the benchmark is underway. You can also configure how many samples to make etc.. Also, benchmarking isn't constrained to whole disks anymore - you can now do it on any volume or block device (for example this RAID-6 array). It's a handy little feature

Of course, the GNOME Disks changes are just the user-visible bits. The "lower half" of the Disks application (basically invisible to end users) is called udisks and happens to be shared with other user interfaces including KDE and all the other user interfaces built on top of GLib/GTK+. For udisks changes, see its git repository for details.

Looking forward to GNOME 3.8

Some of the things I'm planning to work on in the future (hopefully some of it will land in GNOME 3.8) include

• Filesystem/partition resizing - not that interesting of a feature on its own, but incredibly useful in an installer setup where you want to dual-boot with another OS. It shouldn't be that hard to implement since the functionality more or less exists and the main job here is a) add a couple of methods to the Filesystem and Partition D-Bus interfaces; and b) design and implement the UI in Disks. I'm planning to collaborate on the udisks bits with the KDE developer who filed the bug
• Linux MD Raid support in udisks and Disks. We actually had somewhat decent support for this in the old version of udisks/Disks (see these screenshots for example) but it was removed in the rewrite as it was implemented in a hurry without a lot attention to design. Turns out there's still quite a bit of interest from several parties to add back this functionality plus also supporting external metadata and firmware/platform features in a meaningful way. To keep complexity down, we'll probably only allow creating arrays from whole disks as this is the recommended way to do RAID (users can still use mdadm(8) to create arrays on partitions if they so desire)
• Simple iSCSI initiator support - there's already git branches for this in the gnome-disk-utility and udisks repos but it's probably somewhat out of date by now. Anyway, the idea is really simple - just provide a simple front-end to the most common features provided by Linux Open-iSCSI. Some old screenshots showing the work I've already done are here and here

Now an obvious question comes to mind: why should Disks support complicated stuff like MD-RAID and iSCSI? Honestly, for the last couple of years, I've been bouncing back and forth between wanting / not wanting complicated and advanced features like this. However, recent discussions in the GNOME community has put me on a trajectory where I'm more and more convinced that GNOME should try harder to cater to, uh, workstation users (for want of a better word).

If workstations are part of GNOME's mission statement then it follows that you want to enable users to, say, easily set up a beefy workstation with eight disks in a RAID configuration so rebuilding the OS goes faster, easily connect to the lab SAN for if you're into science and so on. Things like that. No matter how good, user-friendly and well-documented commands and configuration files are, I don't think saying "just use the command-line or edit this or that file in /etc" is a super-satisfying answer.