[REVIEW] Storage mounting API

[Jan Synacek]

As a follow-up to the
https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-February/0000..., I'm
hereby presenting the first version of the storage mounting API (attached).

This API doesn't include handling of /etc/fstab. That will be taken care of
later and differently.

-- 
Jan Synacek
Software Engineer, Red Hat

[Jan Safranek]

On 03/13/2013 04:29 PM, Jan Synacek wrote:
>  class LMI_Mount : CIM_Mount
>  {
>      [ Description (
>          "Type of filesystem to create."),
>        ValueMap { "0", "2", "3", "4",
> "5", "6", "7", "8", "9",
> "10",
>                   "11", "12", "13", "..",
>                   "32769", "32770", "32771",
> "32772", "32773", "32768" },
>        Values { "Unknown", "UFS", "HFS", "FAT",
> "FAT16", "FAT32",
>                 "NTFS4", "NTFS5", "XFS", "AFS",
> "EXT2", "EXT3",
>                 "REISERFS", "DMTF Reserved",
>                 "EXT4", "BTRFS", "JFS", "TMPFS",
> "VFAT", "OTHER"} ]
>      uint16 FileSystemType;
>  
>      [ Description (
>          "Specifies filesystem type other than listed in FileSystemType.") ]
Probably "Specifies filesystem type when FileSystemType property is set
to Other." And please use Other instead of OTHER, it's not an abbreviation.


>  class LMI_MountSetting : CIM_SettingData
>  {
>      [ Description (
>          "Other mount options that can be filesystem specific. This property is
> "
>          "also used to specify options with values (e.g. uid=0 or gid=100). "
>          "Other options are appended to the basic options."),
>      string OtherOptions[]; 
I would explicitly note that the mount options are used in the same
order as in this array. Also add ArrayType("Indexed") qualifier to
emphasize this.


>  class LMI_MountService : CIM_Service
>  {
>      uint32 CreateMount(
>          [ IN, Description (
>             "Existing filesystem that should be mounted.") ]
>          CIM_FileSystem REF FileSystem,
>  
>          [ IN, Description (
>              "Type of filesystem."),
>            ValueMap{ "0", "2", "3", "4",
> "5", "6", "7", "8", "9",
> "10",
>                      "11", "12", "13", "..",
>                      "32769", "32770", "32771",
> "32772", "32773", "32768" },
>            Values { "Unknown", "UFS", "HFS",
> "FAT", "FAT16", "FAT32",
>                     "NTFS4", "NTFS5", "XFS",
> "AFS", "EXT2", "EXT3",
>                     "REISERFS", "DMTF Reserved",
>                     "EXT4", "BTRFS", "JFS",
> "TMPFS", "VFAT", "OTHER"} ]
>          uint16 FileSystemType, 
We already know the FS type from FileSystem parameter, FileSystemType
seems to be redundant.

>  
>          [ IN, Description (
>              "Directory where the mounted filesystem should be attached at.") ]
>          string MountPoint,
>  
>          [ IN, Description (
>              "Desired mount settings. If NULL, defaults will be used. Default "
>              "mount options are 'rw, suid, dev, exec, auto, nouser,
> async'.") ]
>          LMI_MountSettings REF Goal,
>  
>          [ IN(false), OUT, Description (
>              "Reference to the created job.") ]
>          CIM_ConcreteJob REF Job 
There should be output parameter Mount with the created mount.

>      );
>  
>      [ Description (
>          "Modifies (remounts) an existing mount." ),
>        ValueMap { "0", "1", "2", "3",
> "4", "5", "6", "..", "4096",
>                   "4097", "4098..32767", "32768..65535" },
>        Values { "Job Completed with No Error", "Not Supported",
>                 "Unknown", "Timeout", "Failed",
> "Invalid Parameter",
>                 "In Use", "DMTF Reserved",
>                 "Method Parameters Checked - Job Started",
>                 "Size Not Supported", "Method Reserved", "Vendor
> Specific" } ]
>      uint32 ModifyMount(
>          [ IN, Description (
>              "An existing mount.") ]
>          LMI_Mount REF Mount, 
Shouldn't it be also output parameter? That's how we do it in CIM.

>  
>          [ IN, Description (
>             "Desired mount settings. If NULL, defaults will be used. Default "
>             "mount options are 'rw, suid, dev, exec, auto, nouser,
> async'.") ]
>          LMI_MountSettings REF Goal,
>  
>          [ IN(false), OUT, Description (
>              "Reference to the created job.") ]
>          CIM_ConcreteJob REF Job
>      ); 
Otherwise it looks well, good job!

Jan

[REVIEW v2] Storage mounting API

[Jan Synacek]

On 03/14/2013 10:10 AM, Jan Safranek wrote:
>  On 03/13/2013 04:29 PM, Jan Synacek wrote:
> > class LMI_Mount : CIM_Mount
> > {
> >     [ Description (
> >         "Type of filesystem to create."),
> >       ValueMap { "0", "2", "3", "4",
> "5", "6", "7", "8", "9",
> "10",
> >                  "11", "12", "13", "..",
> >                  "32769", "32770", "32771",
> "32772", "32773", "32768" },
> >       Values { "Unknown", "UFS", "HFS",
> "FAT", "FAT16", "FAT32",
> >                "NTFS4", "NTFS5", "XFS",
> "AFS", "EXT2", "EXT3",
> >                "REISERFS", "DMTF Reserved",
> >                "EXT4", "BTRFS", "JFS",
> "TMPFS", "VFAT", "OTHER"} ]
> >     uint16 FileSystemType;
> >
> >     [ Description (
> >         "Specifies filesystem type other than listed in FileSystemType.")
> ]
>  
>  Probably "Specifies filesystem type when FileSystemType property is set
>  to Other." And please use Other instead of OTHER, it's not an abbreviation.
>  
>  
> > class LMI_MountSetting : CIM_SettingData
> > {
> >     [ Description (
> >         "Other mount options that can be filesystem specific. This property is
> "
> >         "also used to specify options with values (e.g. uid=0 or gid=100).
> "
> >         "Other options are appended to the basic options."),
> >     string OtherOptions[];
>  
>  I would explicitly note that the mount options are used in the same
>  order as in this array. Also add ArrayType("Indexed") qualifier to
>  emphasize this.
>  
>  
> > class LMI_MountService : CIM_Service
> > {
> >     uint32 CreateMount(
> >         [ IN, Description (
> >            "Existing filesystem that should be mounted.") ]
> >         CIM_FileSystem REF FileSystem,
> >
> >         [ IN, Description (
> >             "Type of filesystem."),
> >           ValueMap{ "0", "2", "3", "4",
> "5", "6", "7", "8", "9",
> "10",
> >                     "11", "12", "13", "..",
> >                     "32769", "32770", "32771",
> "32772", "32773", "32768" },
> >           Values { "Unknown", "UFS", "HFS",
> "FAT", "FAT16", "FAT32",
> >                    "NTFS4", "NTFS5", "XFS",
> "AFS", "EXT2", "EXT3",
> >                    "REISERFS", "DMTF Reserved",
> >                    "EXT4", "BTRFS", "JFS",
> "TMPFS", "VFAT", "OTHER"} ]
> >         uint16 FileSystemType,
>  
>  We already know the FS type from FileSystem parameter, FileSystemType
>  seems to be redundant.
>  
> >
> >         [ IN, Description (
> >             "Directory where the mounted filesystem should be attached
> at.") ]
> >         string MountPoint,
> >
> >         [ IN, Description (
> >             "Desired mount settings. If NULL, defaults will be used. Default
> "
> >             "mount options are 'rw, suid, dev, exec, auto, nouser,
> async'.") ]
> >         LMI_MountSettings REF Goal,
> >
> >         [ IN(false), OUT, Description (
> >             "Reference to the created job.") ]
> >         CIM_ConcreteJob REF Job
>  
>  There should be output parameter Mount with the created mount.
>  
> >     );
> >
> >     [ Description (
> >         "Modifies (remounts) an existing mount." ),
> >       ValueMap { "0", "1", "2", "3",
> "4", "5", "6", "..", "4096",
> >                  "4097", "4098..32767", "32768..65535"
> },
> >       Values { "Job Completed with No Error", "Not Supported",
> >                "Unknown", "Timeout", "Failed",
> "Invalid Parameter",
> >                "In Use", "DMTF Reserved",
> >                "Method Parameters Checked - Job Started",
> >                "Size Not Supported", "Method Reserved",
> "Vendor Specific" } ]
> >     uint32 ModifyMount(
> >         [ IN, Description (
> >             "An existing mount.") ]
> >         LMI_Mount REF Mount,
>  
>  Shouldn't it be also output parameter? That's how we do it in CIM.
>  
> >
> >         [ IN, Description (
> >            "Desired mount settings. If NULL, defaults will be used. Default
> "
> >            "mount options are 'rw, suid, dev, exec, auto, nouser,
> async'.") ]
> >         LMI_MountSettings REF Goal,
> >
> >         [ IN(false), OUT, Description (
> >             "Reference to the created job.") ]
> >         CIM_ConcreteJob REF Job
> >     );
>  
>  Otherwise it looks well, good job!
>  
>  Jan
>   
Fixed. Also, I added two association classes needed to connect LMI_Mount with
LMI_MountSetting and LMI_MountService with LMI_MountCapabilities.

-- 
Jan Synacek
Software Engineer, Red Hat

[REVIEW v2] Storage mounting API

[Jan Safranek]

On 03/14/2013 12:40 PM, Jan Synacek wrote:

>   Also, I added two association classes needed to connect LMI_Mount
> with
>  LMI_MountSetting and LMI_MountService with LMI_MountCapabilities. 

>  [ Association ]
>  class LMI_MountElementSettingData : CIM_ElementSettingData
>  {
>      [ Override("ManagedElement"), Description (
>          "LMI_Mount reference." ) ]
>      CIM_ManagedElement REF ManagedElement
>  
>      [ Override("SettingData"), Description (
>          "LMI_MountSetting reference." ) ]
>      CIM_SettingData REF SettingData
>  }; 
Umm, LMI_Mount is not CIM_ManagedElement. It seems we cannot inherit
CIM_ElementSettingData here. We can make LMI_MountElementSettingData
without any superclass and just pretend it behaves like
CIM_ElementSettingData.

Jan.

[REVIEW v3] Storage mounting API

[Jan Synacek]

On 03/14/2013 12:54 PM, Jan Safranek wrote:
>  On 03/14/2013 12:40 PM, Jan Synacek wrote:
>  
> >  Also, I added two association classes needed to connect LMI_Mount with
> > LMI_MountSetting and LMI_MountService with LMI_MountCapabilities.
>  
>  
> > [ Association ]
> > class LMI_MountElementSettingData : CIM_ElementSettingData
> > {
> >     [ Override("ManagedElement"), Description (
> >         "LMI_Mount reference." ) ]
> >     CIM_ManagedElement REF ManagedElement
> >
> >     [ Override("SettingData"), Description (
> >         "LMI_MountSetting reference." ) ]
> >     CIM_SettingData REF SettingData
> > };
>  
>  Umm, LMI_Mount is not CIM_ManagedElement. It seems we cannot inherit
>  CIM_ElementSettingData here. We can make LMI_MountElementSettingData
>  without any superclass and just pretend it behaves like
>  CIM_ElementSettingData.
>  
>  Jan.
>   
Attached is a slightly modified version, that doesn't use the Mount class at all.

-- Class Methods API --

class MountConfigurationService {
    CreateMount(
        [OUT] Job: ref CIM_ConcreteJob
        [OUT] Mount: ref MountedFileSystem
        [IN] Filesystem: ref CIM_FileSystem
        [IN] MountPoint: string
        [IN] Goal: ref MountedFileSystemSetting
    )
    ModifyMount(
        [OUT] Job: ref CIM_ConcreteJob
        [OUT] NewMount: ref MountedFileSystem
        [In] Mount: ref MountedFileSystem
        [IN] Goal: ref MountedFileSystemSetting
    )
    DeleteMount(
        [OUT] Job: ref CIM_ConcreteJob
        [In] Mount: ref MountedFileSystem
    )
}

class MountedFileSystemCapabilities {
    CreateSetting(
        [OUT] Goal: ref MountedFileSystemSetting
    )
}

-- Design Notes --

MountedFileSystem corresponds to a /etc/mtab entry. PermanentMount represents an
entry in /etc/fstab.


-- 
Jan Synacek
Software Engineer, Red Hat

[REVIEW v3] Storage mounting API

[Jan Synacek]

On 03/15/2013 02:30 PM, Jan Synacek wrote:
>  
>  Attached is a slightly modified version, that doesn't use the Mount class at all.
>  
>  ...
>  
I have summarized the draft and written some basic documentation at
http://jsynacek.fedorapeople.org/openlmi/

-- 
Jan Synacek
Software Engineer, Red Hat

[REVIEW v3] Storage mounting API

[Jan Safranek]

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/.

>  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'?

>      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?

>  };
>  
>  [ 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.

Jan

[REVIEW v3] Storage mounting API

[Jan Synacek]

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

[REVIEW v3] Storage mounting API

[Jan Safranek]

On 03/19/2013 10:38 AM, Jan Synacek wrote:
>  On 03/19/2013 09:30 AM, Jan Safranek wrote:
> > 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. 
We can reuse LMI_MountConfigurationService, add some
create/modify/delete methods + new LMI_<something about perment
mount>Setting as subclass of LMI_MountedFileSystemSetting (or both
children of common superclass?) + new LMI_<something about perment
mount>Capabilities, again subclass of LMI_MountedFileSystemCapabilities
(or both children of common superclass?)

Jan

[REVIEW v3] Storage mounting API

[Jan Safranek]

On 03/19/2013 10:38 AM, Jan Synacek wrote:
> >> [ 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: 
But you have it a vice versa, directory depends on mount.

Antecedent: MountedSystem
Dependent: Directory

Jan

[REVIEW v3] Storage mounting API

[Karel Zak]

On Tue, Mar 19, 2013 at 10:38:16AM +0100, Jan Synacek wrote:
>  On 03/19/2013 09:30 AM, Jan Safranek wrote:
>  > On 03/18/2013 03:31 PM, Jan Synacek wrote:
>  >>     [ 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 is "none", "bind" is mount flag

>  type. It's just a remount of *the same filesystem* to somewhere
> else. Or am I
>  missing something? 
I have doubts that introduce something like BindDir is a good idea.

It would be better to not think about "bind" as about something
special. The bind *operation* creates a new connection between
a filesystem and target (mountpoint). That's all.

  mount /dev/sda1 /foo
  mount /dev/sda2 /bar

is the same as:

  mount /dev/sda1 /foo
  mount --bind /foo /bar

the difference is that by bind operation you can mount non-root
directory of the filesystem, for example:

  mount --bind /foo/subdir /bar

(the same thing is possible by btrfs subvolumes).

The important is that the "original" mountpoint could be unmounted.
There is not any dependence between the mountpoints (e.g. between /foo
and /bar).

  mount /dev/sda1 /foo 
  mount --bind /foo /bar
  umount /foo 
  rm -rf /foo


The generic rule is to not try to save any information about the current
VFS status somewhere in userspace. If you want to know the current
setting used by your system then always see /proc/self/mountinfo.
Everything else is bogus. We really don't want to introduce another
/etc/mtab :-)

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[REVIEW v3] Storage mounting API

[Jan Synacek]

On 03/19/2013 06:15 PM, Karel Zak wrote:
>  On Tue, Mar 19, 2013 at 10:38:16AM +0100, Jan Synacek wrote:
> > On 03/19/2013 09:30 AM, Jan Safranek wrote:
> >> On 03/18/2013 03:31 PM, Jan Synacek wrote:
> >>>     [ 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 is "none", "bind" is mount flag 
Makes sense. Can there be any other case where the type can be 'none'?

>  
> > type. It's just a remount of *the same filesystem* to somewhere else. Or am I
> > missing something?
>  
>  I have doubts that introduce something like BindDir is a good idea. 
Yes, we came to the same conclusion. BindDir will be removed in the next iteration.

>  
>  It would be better to not think about "bind" as about something
>  special. The bind *operation* creates a new connection between
>  a filesystem and target (mountpoint). That's all.
>  
>    mount /dev/sda1 /foo
>    mount /dev/sda2 /bar
>  
>  is the same as:
>  
>    mount /dev/sda1 /foo
>    mount --bind /foo /bar
>  
>  the difference is that by bind operation you can mount non-root
>  directory of the filesystem, for example:
>  
>    mount --bind /foo/subdir /bar
>  
>  (the same thing is possible by btrfs subvolumes).
>  
>  The important is that the "original" mountpoint could be unmounted.
>  There is not any dependence between the mountpoints (e.g. between /foo
>  and /bar).
>  
>    mount /dev/sda1 /foo 
>    mount --bind /foo /bar
>    umount /foo 
>    rm -rf /foo
>   
I think that the current model should have this covered already.

@jsafrane What do you think?

>  
>  The generic rule is to not try to save any information about the current
>  VFS status somewhere in userspace. If you want to know the current
>  setting used by your system then always see /proc/self/mountinfo.
>  Everything else is bogus. We really don't want to introduce another
>  /etc/mtab :-) 
My understanding is that the information contained in /etc/mtab or
/proc/self/mountinfo will be exposed through the model (class instances).
Furthermore, we will allow manipulation of the information through some of the
methods. Our job is to keep the information synchronized correctly.

>  
>      Karel
>   
Karel, thank you for the insights!

-- 
Jan Synacek
Software Engineer, Red Hat

[REVIEW v3] Storage mounting API

[Karel Zak]

On Wed, Mar 20, 2013 at 08:07:12AM +0100, Jan Synacek wrote:
>  On 03/19/2013 06:15 PM, Karel Zak wrote:
>  > On Tue, Mar 19, 2013 at 10:38:16AM +0100, Jan Synacek wrote:
>  >> On 03/19/2013 09:30 AM, Jan Safranek wrote:
>  >>> On 03/18/2013 03:31 PM, Jan Synacek wrote:
>  >>>>     [ 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 is "none", "bind" is mount flag
>  
>  Makes sense. Can there be any other case where the type can be 'none'? 
 Sure, MS_BIND, MS_MOVE, MS_REMOUNT and MS_PROPAGATION (slave, private, ...)
 ignore filesystem type.
 
 Note that the mount(2) syscall has exactly specified semantic for VFS operations
 (move, bind, propagation flags, etc), BUT for everything else (filesystems 
 specific options) it is pretty liberal. For filesystem specific operations all
 depends on filesystem driver - see for example variability of the mount source 
 string for fuse, nfs, cifs, ...

>  My understanding is that the information contained in /etc/mtab or
>  /proc/self/mountinfo will be exposed through the model (class instances).
>  Furthermore, we will allow manipulation of the information through some of the
>  methods. Our job is to keep the information synchronized correctly. 
 Cool. (BTW, /proc/self/{mounts,mountinfo} files are poll()-able, so
 you can monitor all changes).

 How do you plan to handle namespaces? I mean.. for example "get the list
 of the mounted filesystems" is namespaces specific.

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[Stephen C. Tweedie]

Hi,

On Wed, 2013-03-13 at 16:29 +0100, Jan Synacek wrote:
>  As a follow-up to the
>  https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-February/0000...,
> I'm
>  hereby presenting the first version of the storage mounting API (attached).
>  
>  This API doesn't include handling of /etc/fstab. That will be taken care of
>  later and differently. 
Most of the storage API is currently persistent (naturally!); wouldn't
it be natural for a mounting API to manage fstab transparently?  It
would seem more consistent for mount/unmount operations to be persistent
automatically.

Thanks,
 Stephen

[Stephen C. Tweedie]

Hi,

On Thu, 2013-03-14 at 16:10 +0000, Stephen C. Tweedie wrote:
>  On Wed, 2013-03-13 at 16:29 +0100, Jan Synacek wrote:
>  > As a follow-up to the
>  > https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-February/0000...,
> I'm
>  > hereby presenting the first version of the storage mounting API (attached).
>  > 
>  > This API doesn't include handling of /etc/fstab. That will be taken care of
>  > later and differently.
>  
>  Most of the storage API is currently persistent (naturally!); wouldn't
>  it be natural for a mounting API to manage fstab transparently?  It
>  would seem more consistent for mount/unmount operations to be persistent
>  automatically. 
Actually, it looks like there are some precedents for how to manage
persistent vs. runtime configuration like this.  In the network model,
we use

http://schemas.dmtf.org/wbem/cim-html/2.35.0+/CIM_ElementSettingData.html

which has various ways to refine the semantics of a config option,
including "isNext" which indicates a setting that will be applied on
reset/reconfiguration (which looks like it could map directly to whether
or not an entry is in fstab.)

Radek Novacek can describe better how this is used in the networking
models.  If it looks useful, it would be ideal if we can do this
consistently between networking and filesystems, as ports and mount
points have similar distinctions between current and on-reboot
configurations.

In particular, this would avoid having a subclass for persistent mounts,
which would mean we'd be able to keep the same existing class for a
mounted filesystem when we add or remove it in fstab.

Thanks,
 Stephen

[REVIEW v4] Storage mounting API

[Jan Synacek]

Version 4 can be found at http://jsynacek.fedorapeople.org/openlmi/

-- 
Jan Synacek
Software Engineer, Red Hat

[REVIEW v4] Storage mounting API

[Jan Safranek]

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

[REVIEW v4] Storage mounting API

[Jan Synacek]

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

[REVIEW v4] Storage mounting API

[Jan Safranek]

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.

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.

Jan

[REVIEW v4] Storage mounting API

[Karel Zak]

On Mon, Mar 25, 2013 at 10:20:38AM +0100, Jan Safranek wrote:
>  >     [ 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. 
 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 :-)

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[REVIEW v4] Storage mounting API

[Jan Synacek]

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