[REVIEW v3] Storage mounting API

Jan Synacek jsynacek at redhat.com
Wed Mar 20 07:07:12 UTC 2013


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


More information about the openlmi-devel mailing list