Design of mounting in OpenLMI-Storage

Jan Safranek jsafrane at redhat.com
Wed Feb 27 09:32:53 UTC 2013


Hi,
we should do some mounting in OpenLMI storage provider and I want to
discuss its design.
(sorry for HTML, is there any better way how to send such proposals?)

  * SMASH and DASH do not cover mounting of filesystems.
  * SMI-S has Filesystem Manipulation Profile, but it's closely tight to
    filesystem management, for example:
      o Filesystems are mounted using SNIA_CreateFileSystem method, i.e.
        it's possible to create & mount a FS in one call, but it's weird
        to call SNIA_CreateFileSystem to mount existing FS (but it's
        possible).
      o Filesystems can be mounted only once.
      o Only local filesystems can be mounted.

CIM provides lot of classes to manage mounts:

  * CIM_Mount - association between a FS and a directory, where it's
    mounted.
  * CIM_FileImportService - service, which mounts remote filesystems
    (NFS, CIFS) + usual Setting & Capabilities classes

There is no service which mounts local filesystems!

So, looking at the CIM_FileImportService, we might get inspired by it
and create following classes:

  * LMI_MountService
      o CreateMount(FS, type, mountpoint, goal, permanent)
          + FS: reference to either Local or RemoteFileSystem or NULL.
          + type: uint16, enum (nfs, cifs, xfs, ext2/3/4, vfat, ...).
          + mountpoint: string (or reference to LMI_Directory?).
          + goal: reference to LMI_MountSettings or NULL to use default.
          + permanent: boolean, whether to store in fstab.
          + if FS is NULL, type can be used to create tmpfs, sysfs,
            procfs, cgroups, ...
          + LMI_Mount is created with attached LMI_MountSetting.
      o Remote file systems are represented by RemoteFileSystem, but how
        to enumerate them when they are not mounted? We probably don't
        want to scan the network for available NFS/CIFS shares. We might
        add a method to create such RemoteFileSystem and mount it using
        CreateMount(), but I propose following function:
      o CreateRemoteMount(specifier, type, mountpoint, permanent)
          + specifier: string like 'foo:/home/jsafrane' for NFS or
            '//foo/home/jsafrane' for CIFS.
          + type, mountpoint, goal, permanent: same as above.
          + Appropriate CIM_RemoteFileSystem gets created.
          + LMI_Mount is created with attached LMI_MountSetting.
      o ModifyMount(mount, goal, permanent)
          + mount: reference to existing LMI_Mount.
          + goal: reference to new LMI_MountSettings of the mount.
          + permanent: whether to store this mount in fstab.
              # if the mount was permanent and is not anymore, it gets
                removed from fstab.
              # if the mount was not permanent and is now, it gets added
                to fstab.
              # if the mount was permanent and still is, fstab is edited.
      o DeleteMount(mount)
          + mount: reference to existing LMI_Mount.
      o All these methods return Job (mounting can take some time, right?)
  * LMI_Mount: inherited from CIM_Mount
      o Association between a CIM_FileSystem (local or remote) and
        CIM_Directory where it's mounted.
      o Has property if this mount is permanent (in fstab).
      o Has property if this mount is active (i.e. currently mounted).
      o There can be LMI_Mount, which does not exist on the system, but
        has entry in fstab!
          + e.g. when admin remounts a mount which is in fstab with
            different options, there will be two LMI_Mount instances.
              # One for the fstab mount (inactive, permanent).
              # One for the actual mount (active, not permanent).
              # OpenLMI can edit both.
              # One of the mount instances disappears when fstab and
                running system gets in sync.
          + /We must add new key to the association to //distinguish
            multiple mounts of one fs to the same directory, just with
            different options and permanent/non permanent flag./
          + /There can be only one fstab entry for (device, directory)
            pair./
      o If there is an entry in fstab but the filesystem (or block
        device) is not available, no LMI_Mount is created!
          + /How to edit/delete such leftovers? Maybe the device was
            just renamed./
  * LMI_MountSetting
      o Configuration of a mount.
      o Has properties for selected mount options
          + ro
          + rw
          + Anything else? We may gradually extend this class and even
            make subclasses for each FS, e.g. have LMI_Ext2MountSetting,
            LMI_XFSMountSetting, LMI_NFSMountSetting, ...
      o Has generic array of strings of 'additional options' for all
        mount options, which are not covered by specific properties.
      o Is associated with LMI_Mount to shows its configuration.
          + /LMI_Mount is association, i.e. we have association between
            association and MountSetting, which is slightly confusing./
  * LMI_MountCapabilities
      o Capabilities of the MountService, as usual in SMI-S and LMI
        storage model.

UML class diagram
This CIM API does not follow any DMTF or SMI-S standard, but follows the
idea of it - have a Service, Setting and Capabilities classes and can be
extended in the future.

Later we still may implement CIM_FileImportService if someone wants, but
it would be just a wrapper around our MountService.

In Fedora19 I think we can do only 'transient' mounts, no fstab editing,
Blivet doesn't support non-destructive fstab manipulation now. In
addition, Blivet does support mounting of local filesystems on block
devices for now (no cgroups, sysfs, procfs, tmpfs, ...), but even this
limited functionality is IMHO quite lot of work on OpenLMI side.

Any comments are welcome, especially the parts in /italics/ are quite
disturbing to me. And links to any model which already covers mounting
would be greatly appreciated.

Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20130227/f5939443/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mounting.svg
Type: image/svg+xml
Size: 13147 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20130227/f5939443/attachment-0001.svg>


More information about the openlmi-devel mailing list