[REVIEW v4] Storage mounting API

Jan Synacek jsynacek at redhat.com
Wed Mar 27 11:32:36 UTC 2013


On 03/25/2013 10:20 AM, Jan Safranek wrote:
> On 03/22/2013 09:24 AM, Jan Synacek wrote:
>> On 03/21/2013 02:03 PM, Jan Safranek wrote:
>>> On 03/20/2013 11:07 AM, Jan Synacek wrote:
>> {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?
> 
> Now the mof file looks good to me. As for create(), I'd rather return
> error, when the mount already exists + add lot of examples to
> documentation when/how to call Create and Modify.

Done.

> 
> Also a minor nitpicking:
> 
>> [ Description (
>>     "Class for representing mounted filesystems. Can be thought of as an entry "
>>     "in /etc/mtab." ) ]
>> class MountedFileSystem : CIM_ManagedElement
> ...
>>     [ Key, Description (
>>         "Filesystem specification. Corresponds to the device field in "
>>         "/etc/fstab." ) ]
>>     string FileSystemSpec;
> 
> I would write that the MountedFileSystem can represent both /etc/mtab
> and /etc/fstab entry, depending on its associated Settings.

Done.

Also, maybe we should stop using /etc/mtab as a place in the system that we are
modelling. Quoting Karel Zak from another email in this thread:

>  Note, maybe one day you will find that mtab format does not provide enough
>  information and you will want to use /proc/self/mountinfo :-)
> 
>  The ideal solution is to use libmount abstraction to transparently
>  work with old systems where is /etc/mtab as well with new systems
>  where we prefer /proc/self/mountinfo. 
>  
>  On systems without mtab the libmount library also maintains some
>  information in userspace (for filesystems like NFS) in *private*
>  libmount file /run/mount/utab. All this is accessible by findmnt(8)
>  (see --kernel and --mtab).
> 
>  Anyway, for now it's probably good enough to follow mtab to keep it
>  simple and stupid :-)

I know that we won't be reading /etc/mtab or /proc/mounts directly. Our model
will not change because of that too. But I think we should stop using /etc/mtab
as something that MountedFileSystem instances can be likened to. For example,
there is no way you can tell bind mounts by just looking at /etc/mtab (which
links to /proc/mounts on my system). But, by using findmnt(8), I can tell which
mounts are mounted using the bind operation.

-- 
Jan Synacek
Software Engineer, Red Hat


More information about the openlmi-devel mailing list