[Pkg-sysvinit-devel] Bug#494001: `mount -o loop' runs out of loop devices

[Roger Leigh]

On Thu, Jun 04, 2009 at 12:43:29AM +1000, Kel Modderman wrote:
> CC'ing Roger.
> 
> On Saturday 30 May 2009 21:49:16 Dmitry Maksyoma wrote:
> > 
> > Just to let you know: when /etc/mtab is a symlink to /proc/mounts, loop devices
> > aren't freed by umount and the system may run out of loop devices (which makes
> > things worse than they were with old-style mtab). Apparently, it's not a bug, as
> > it's documented in mount(8):
> > 
> > If you are not so unwise as to make /etc/mtab a symbolic link to /proc/mounts
> > then any loop device allocated by  mount  will  be freed by umount.  You can
> > also free a loop device by hand, using `losetup -d', see losetup(8).
> > 
> 
> Thanks for pointing it out Dmitry.
> 
> Symlinking of mtab to /proc/mounts also seems to change/stop the user= mount
> option from working properly.

I think this may be a red herring.  The mount(8) manual page says a lot
of incorrect things about missing information in /proc/mounts which
is present in /etc/mtab.  However, with a current kernel all of the
information is there.

If umount was failing due to insufficient information, this is a non-
issue since all kernels from stable up support it.

If umount behaves differently if /etc/mtab is a symlink, then that's
a nasty bug in mount that needs fixing.  It's probably a trivial fix
to remove the special case handling of the symlink, if such a special
case is present.

> Do the benefits of symlinking mtab -> mounts outweigh possible regressions
> related to loop device mounting or user= mount option?

Yes.  For all the reasons given in the report.  Additionally,
it fixes a *lot* of bugs in mount, where mount would royally screw up
/etc/mtab when it got confused, or would misbehave due to having
incomplete information in /etc/mtab.  Things like "rbind" which are
used far more commonly than "loop" are basically broken with /etc/mtab
as a file.  With /etc/mtab as a symlink, it always represents the
current state of the system; it can't get out of date or corrupted.

However, if Dmitry can confirm this is a real bug (as opposed to a
documentation issue, in which case it still needs a bug against
mount), then the solution is fixing mount rather than not fixing this
bug.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.