Skip to content

Instantly share code, notes, and snippets.

@allenap
Last active February 9, 2016 16:16
Show Gist options
  • Save allenap/dc5a3a790c551951db2f to your computer and use it in GitHub Desktop.
Save allenap/dc5a3a790c551951db2f to your computer and use it in GitHub Desktop.

How MAAS passes mount options to curtin

In the storage configuration that MAAS passes to curtin it includes stanzas like:

- id: sda-part5_mount
  type: mount
  path: /srv
  options: rw,nosuid,nodev,noexec,relatime
  device: sda-part5_format

which may contain an options field. This is used for the fs_mntops field in fstab(5). Curtin does not attempt to merge additional options into this; the sender is considered authoritative.

If MAAS does not provide an options field:

- id: sda-part5_mount
  type: mount
  path: /srv
  device: sda-part5_format

or if MAAS passes null:

- id: sda-part5_mount
  type: mount
  path: /srv
  options: null
  device: sda-part5_format

or if MAAS passes the empty string:

- id: sda-part5_mount
  type: mount
  path: /srv
  options: ""
  device: sda-part5_format

then curtin is requested to do what it thinks best. For example, curtin might set noatime for /tmp, or errors=remount-ro for /.

MAAS should be able to ask curtin what options it would choose for a given filesystem type and mount point. These options would be displayed in the Web UI and made available via the Web API so that users and administrators of MAAS can make informed decisions when setting mount options.

Why this way?

Having curtin merge user-supplied options into its own set of options was considered. However, it was rejected because:

  • There would be a hard requirement to inform the user how the mix of the user's and curtin's options would be resolved. This compares unfavourably with the soft requirement for showing curtin's default mount options and allowing the user to merge.

  • Curtin would have to be smart about merging options. For example, atime and noatime conflict, and it would need to know to eliminate one. In addition, each filesystem defines its own distinct set of options which can vary with kernel version. The work demanded to reliably detect and resolve conflicts and to keep up with changes may be considerable.

Having MAAS be smarter was also rejected (with the exception of maybe ensuring that errors=remount-ro is used on root mounts) on the basis that it would make MAAS too option-aware and so be as complex to maintain as curtin if it were made smarter.

Other considerations

Root filesystems should be mounted with the errors=remount-ro option. MAAS may incorporate smarts to ensure that this is always the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment