[REVIEW v3] Storage mounting API

Karel Zak kzak at redhat.com
Tue Mar 19 17:15:25 UTC 2013


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 at redhat.com>
 http://karelzak.blogspot.com


More information about the openlmi-devel mailing list