open-sharedroot-devel

Re: [OSR-devel] /etc/mtab

[Marc G. <gr...@at...>]

----- "Gordan Bobic" <go...@bo...> wrote:

> Is there a particular functional reason why /etc/mtab should be 
> symlinked to /proc/mounts instead of /cdsl.local/etc/mtab?
Yes there is.
> 
> The reason I ask two-fold:
> 
> 1) I'm not sure if having it symlinked to /proc/mounts confuses the 
> process of unmounting the file systems in the shared root during 
> shutdown. /proc/mounts shows all mounted file systems, including paths
> 
> that aren't mounted in the OSR root (e.g. /mnt/tmproot for the glfs 
> backing fs is mounted only in the initroot, but still shows up in 
> /proc/mounts).
> 
> 2) It seems to interfere with the checks to see whether a bind-mount
> is 
> already mounted. Under OSR, I'm seeing all bind-mounts in fstab
> getting 
> mounted twice, once when mounting local file systems, and once when 
> mounting "other" file systems.
This can be changed. Just add an options _netdev as option to the fstab an the bindmounts should only be mounted once.
> 
> Is anything likely to break if /etc/mtab is symlinked to 
> /cdsl.local/etc/mtab?
Yes.
First see:
https://partner-bugzilla.redhat.com/show_bug.cgi?id=214891
Then when mount <path> is executed with RHEL5 the following is done (if I recall it right).
All changes are done to a tmpfile /etc/mtab.tmp and this version gets newly created in /etc and afterwards copied back to /etc/mtab. The symlink to /cdsl.local does not survive. But if /etc/mtab is a symlink to /proc/mounts all of the above is ignored.

That's how I recall the background of this topic.

As this is in phase of being change it might be that there are changes already in RHEL5 latest U but not very likely.

It is easily to be tested:
rm /etc/mtab; touch /cdsl.local/etc/mtab; ln -s /cdsl.local/etc/mtab /etc/mtab; mount <somepath>; ls -l /etc/mtab.

Hope this helps
Marc
> 
> Gordan
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast
> and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-devel] /etc/mtab

[Gordan B. <go...@bo...>]

Marc Grimme wrote:

>> The reason I ask two-fold:
>>
>> 1) I'm not sure if having it symlinked to /proc/mounts confuses the 
>> process of unmounting the file systems in the shared root during 
>> shutdown. /proc/mounts shows all mounted file systems, including paths
>>
>> that aren't mounted in the OSR root (e.g. /mnt/tmproot for the glfs 
>> backing fs is mounted only in the initroot, but still shows up in 
>> /proc/mounts).
>>
>> 2) It seems to interfere with the checks to see whether a bind-mount
>> is 
>> already mounted. Under OSR, I'm seeing all bind-mounts in fstab
>> getting 
>> mounted twice, once when mounting local file systems, and once when 
>> mounting "other" file systems.
 >
> This can be changed. Just add an options _netdev as option to the fstab an the bindmounts should only be mounted once.

I thought about that, but it's a bit of a bodge. It can end up 
interfering with the unmounting order on shutdown since it makes all of 
those file systems unmount via the netfs init script rather than halt.

>> Is anything likely to break if /etc/mtab is symlinked to 
>> /cdsl.local/etc/mtab?
> Yes.
> First see:
> https://partner-bugzilla.redhat.com/show_bug.cgi?id=214891
> Then when mount <path> is executed with RHEL5 the following is done (if I recall it right).
> All changes are done to a tmpfile /etc/mtab.tmp and this version gets newly created in /etc and afterwards copied back to /etc/mtab. The symlink to /cdsl.local does not survive. But if /etc/mtab is a symlink to /proc/mounts all of the above is ignored.
> 
> That's how I recall the background of this topic.
> 
> As this is in phase of being change it might be that there are changes already in RHEL5 latest U but not very likely.

I see. That is, indeed a problem. :-/
Of course, going to OpenVZ guest root as mentioned in my other post 
would work around this (if it works at all, but that's something I'm 
planning to find out relatively soon).
*whistles innocently* ;)

Gordan