[REVIEW v4] Storage mounting API

Jan Safranek jsafrane at redhat.com
Thu Mar 21 13:03:08 UTC 2013


On 03/20/2013 11:07 AM, Jan Synacek wrote:
> Version 4 can be found at http://jsynacek.fedorapeople.org/openlmi/
> 

> class LMI_MountedFileSystemSetting : CIM_SettingData
>     [ Description (
>         "This field is used for these filesystems by the dump(8) command to "
>         "determine which filesystems need to be dumped. If the field is "
>         "not present, a value of zero is returned and dump will assume that "
>         "the filesystem does not need to be dumped." ) ]
>     boolean Dump;
> 
>     [ Description (
>         "Used by the fsck(8) program to determine the order in which "
>         "filesystem checks are done at reboot time. The root filesystem should "
>         "be specified with a 1, other filesystems with a 2. Filesystems within "
>         "a drive are checked sequentially, but filesystems on different drives "
>         "are checked in parallel." ) ]
>     int FileSystemCheckOrder;

I would add a note that these properties are relevant only to fstab,
i.e. setting with isNext=True.

And because we have fstab and mtab in one setting, I miss 'user' and
'auto' options.

> class LMI_MountConfigurationService : CIM_Service
>         [ IN, Description (
>            "Existing filesystem that should be mounted. If NULL, mount a "
>            "non-local filesystem. If not NULL, mount a local filesystem. When "
>            "mounting a local filesystem, the FileSystemType parameter has to "
>            "agree with the type of FileSystem." ) ]
>         CIM_FileSystem REF FileSystem,

If NULL, mount remote filesystem or create non-device filesystem, like
tmpfs.

> 
>         [ IN, Description (
>             "Filesystem specification. Specifies the device that should be "
>             "mounted." ) ]
>         string FileSystemSpec,

I would emphasize that FileSystemSpec can contain NFS and CIFS in
'usual' format (hostname:/share and //hostname/share) and also 'name'
for non-device filesystems like tmpfs or sysfs.

>     uint32 ModifyMount(
>         [ IN(false), OUT, Description (
>             "Reference to the created job." ) ]
>         CIM_ConcreteJob REF Job,
> 
>         [ IN, OUT, Description (
>             "Reference to the LMI_Mount instance that is being modified. " ) ]
>         LMI_MountedFileSystem REF Mount,
> 
>         [ IN, Description (
>            "Desired mount settings. If NULL, defaults will be used. Default "
>            "mount options are 'rw, suid, dev, exec, auto, nouser, async'." ) ]
>         LMI_MountedFileSystemSetting REF Goal,

For re-mount, I would say that if Goal is NULL, then the mount options
are not changed. And if fstab/mtab entry is being created/mounted, then
appropriate Setting from the other (mtab/fstab) entry is used.

> Service methods perform their operations according to the mode. The table below displays only supported modes. 

The table is nice, still there are some cases missing. E.g. what happens
when a mount already has an entry in fstab and CreateMount(Mode=1) is
called? Is the fstab entry updated? Or ignored?

Jan


More information about the openlmi-devel mailing list