[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