3:24 a.m.
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