[REVIEW v3] Storage mounting API

Jan Synacek jsynacek at redhat.com
Tue Mar 19 09:38:16 UTC 2013


On 03/19/2013 09:30 AM, Jan Safranek wrote:
> On 03/18/2013 03:31 PM, Jan Synacek wrote:
>> I have summarized the draft and written some basic documentation at
>> http://jsynacek.fedorapeople.org/openlmi/
> 
> It looks like mounting is getting more and more complicated :). Now we
> have 14 classes only to call simple mount <what> <where> -o <opts>
> 
>> [ Description (
>>     "Class for representing mount options. Basic boolean properties represent "
>>     "filesystem independent mount options (as listed in mount(8)). Options "
>>     "'auto' and 'user' are ommited, as they only make sense in /etc/fstab." ) ]
>> class LMI_MountedFileSystemSetting : CIM_SettingData
> 
> If 'auto' and 'user' are relevant only to fstab, shouldn't they be in
> some sort of LMI_PermanentMountFileSystemSetting? In addition, Dump and
> FileSystemCheckOrder properties IMHO belongs to a setting class and not
> to managed element - it's /configuration/, not /state/.

Yes, this makes sense. If I get this correctly, this would mean a class for the
service, one for the setting, one for capabilities and then some more for
associations.

>> class MountedFileSystem : CIM_ManagedElement
> 
> What is key of this class?
> 
>>     [ Description (
>>         "If not NULL, specifies a directory path where a part of the original "
>>         "file hierarchy is remounted. Also signifies use of a bind mount." ) ]
>>     string BindDir;
> 
> Huh? What is 'original hierarchy'? Is it source directory of the bind
> mount? Can we merge it with FileSystemType='bind' and
> FileSystemSpec='/bind/source'?

Unfortunate wording, I admit. I'll try to fix that.

I think that FileSystemType=bind makes no sense as bind is not a filesystem
type. It's just a remount of *the same filesystem* to somewhere else. Or am I
missing something?

> 
>>     uint32 ModifyMount(
>> ...
>>         [ IN(false), OUT, Description (
>>             "Reference to the modified LMI_Mount instance." ) ]
>>         LMI_MountedFileSystem REF NewMount,
>>
>>         [ IN, Description (
>>             "An existing mount." ) ]
>>         LMI_MountedFileSystem REF Mount,
> 
> These two should be one Mount parameter, on IN it's the mount to modify,
> on OUT it's the new mount point.
> 
>> [ Association ]
>> class MountPoint: CIM_Dependency
>> {
>>     [ Override("Antecedent"), Description (
>>         "MountedFileSystem reference." ) ]
>>     CIM_ManagedElement REF MountedSystem;
>>
>>     [ Override("Dependent"), Description (
>>         "CIM_Directory reference." ) ]
>>     CIM_Directory REF Directory;
> 
> Is this class really a dependency? Does Directory depend on
> MountedFileSystem?

In a sense, yes, mounted filesystem 'depends' on a directory where it's mounted.
I just wanted to plug the association classes into the CIM model and
CIM_Dependency seemed just about right. Quoting the specification:

"CIM_Dependency is a generic association used to establish dependency
relationships between ManagedElements."

> 
>> };
>>
>> [ Association ]
>> class AttachedFileSystem: CIM_Dependency
>> {
>>     [ Override("Antecedent"), Description (
>>         "MountedFileSystem reference." ) ]
>>     CIM_ManagedElement REF MountedSystem;
>>
>>     [ Override("Dependent"), Description (
>>         "LMI_FileSystem reference." ) ]
>>     CIM_ManageElement REF FileSystem;
> 
> Dtto.
> 
> In addition, we have model with PermanentMount, but there are no methods
> to create/modify it. I know, we don't have any support for it in Blivet
> yet, but if we have the classes, we should also have the methods to
> manipulate them, even though we won't implement them in the first release.

This would be solved by implementing the idea in the first inlined paragraph.

-- 
Jan Synacek
Software Engineer, Red Hat


More information about the openlmi-devel mailing list