While the world is going crazy these days we continue to march in full strength towards the next UDisks release. It’s still a couple of weeks away and there are some interesting features still pending to be merged. With all the changes we’re bound with the promise to keep the public D-Bus and C API stable and that won’t change even that there were major changes under the hood. Overall we’ve been focusing on general stability and predictability, fixing various race conditions. But we’ve also added a couple of new interesting features.
Configurable mount options
UDisks carries a set of predefined mount options for well-known filesystems. With the primary focus on desktop use the defaults were chosen to fit typical use cases. For example the vfat filesystem defaults define the flush mount option being a typical filesystem for removable flash media and it’s important to make write operations more synchronous to prevent users tearing their drives out while kernel still writing back the cached data. Such defaults may not suit everyone and users were asking for a way to change that. We’ve even been receiving contradicting merge requests to add or remove certain mount option. Some users on public forums even suggested modifying the udisksd binary how ridiculous may that sound.
There were couple of patches and suggestions in the past that served as a valuable feedback. At the end we decided to combine the best ideas and allow redefining mount options by the config file and from udev rules as each approach has specific use cases. Each way has a defined priority so e.g. udev rules would cover the config file definitions. As redefining and allowing certain mount options may have severe security implications, only a sysadmin owned global config file in /etc/udisks2 and udev rules are considered. Redefining mount options may serve either for lockdown purposes or for a more liberal environment.
Comprehensive documentation will be provided along the API docs as this is pretty complex topic. Just a glimpse of how the current config file syntax currently looks like:
[defaults]
allow=exec,noexec,nodev,nosuid,atime,noatime,nodiratime,ro,rw,sync,dirsync,noload
vfat_defaults=uid=$UID,gid=$GID,shortname=mixed,utf8=1,showexec,flush
vfat_allow=uid=$UID,gid=$GID,flush,utf8,shortname,umask,dmask,fmask,codepage,iocharset
# common options for both the native kernel driver and exfat-fuse
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro
exfat_allow=uid=$UID,gid=$GID,dmask,errors,fmask,iocharset,namecase,umask
ntfs_defaults=uid=$UID,gid=$GID,windows_names
ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names
...D-Bus object properties updates
The reach of UDisks has evolved in recent years from being a simple automounter backend to a complete stateful storage management API. UDisks has gained internal modularity for non-standard storage technologies (more on that in upcoming blog posts!) and is more often used in scripts. Historically the design and intended use was mostly asynchronous where clients were supposed to hook up on D-Bus signals and just update the GUI afterwards. Properties on D-Bus objects were updated usually as a result of incoming uevent, often significantly later after a method call returned. That caused race conditions on client side that expected all D-Bus properties being up-to-date once a method call returns.
We embraced the work done by Peter Rajnoha on synthetic uevent tagging that’s available since Linux kernel 4.13.0. When we expect properties being updated as a result of native uevent we queue a synthetic one with a tag and we wait until it’s received. The uevent queue is more or less serialized and this makes sure the queue is fully processed before the tag. This allows us to hold on returning from a method call and let the objects be updated with fresh data from udev. When running UDisks on older Linux kernels the new measure has no effect and works just like before.
This however brings a change the clients may observe – the D-Bus property change notifications are fired earlier. I’m not sure there was any (API stability) guarantee with regards to D-Bus properties anywhere, this might however need attention in your application.
VDO (Virtual Data Optimizer)
While you might not be aware of what VDO is or does as the kvdo kernel module still hasn’t been upstreamed and adopted by major distributions, UDisks 2.8.0 brought a basic vdo module that runs on top of standalone vdo/vdo-manager commands. There were a couple of design shortcomings leading from VDO limitations itself and together with little to no adoption of this module and recent integration of dm-vdo in LVM a decision has been made to prefer the new lvmvdo integration coming in UDisks 2.9.0 and deprecate the standalone vdo module instead.
All this work is based on libblockdev support in case a stateless API fits you more.
There are even more changes queued for the 2.9.0 release, stay tuned for upcoming articles about UDisks, the API and practical use cases!
