[REVIEW v4] Storage mounting API

Jan Synacek jsynacek at redhat.com
Fri Mar 22 08:24:43 UTC 2013


On 03/21/2013 02:03 PM, Jan Safranek wrote:
> 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
> 

MOF file updated.


{Create,Modify,Delete}Mount() methods should only do what they say, meaning that
CreateMount() shouldn't modify anything. I would say, that if
CreateMount(Mode=1) is called and there already exists an fstab entry, only
mount should be performed. The same with other methods. The mode, in my opinion,
should reflect the state *after* the method call.

On the other hand, if I attempt to mount something that is already mounted via
the mount(8) command, an error is raised.

What do you think?

-- 
Jan Synacek
Software Engineer, Red Hat


More information about the openlmi-devel mailing list