Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Mon, Sep 20, 2004 at 08:20:26AM -0700, Eric Sandall wrote:
> Shall we update util-linux?
> 
> -sandalle

Updated in devel and test.

> ----- Forwarded message from Andries.Brouwer AT cwi.nl -----
>     Date: Mon, 20 Sep 2004 00:05:02 +0200 (MEST)
>     From: Andries.Brouwer AT cwi.nl
> Reply-To: Andries.Brouwer AT cwi.nl
>  Subject: OOM & [OT] util-linux-2.12e
>       To: linux-kernel AT vger.kernel.org
> 
> Just released (on ftp.win.tue.nl in /pub/linux-local/utils/util-linux)
> util-linux-2.12e.
> 
> The reason for this release were complaints that mount and umount
> OOM the kernel when the number of mounts is large.
> And indeed - I tried with 30000 mounts and the OOM-killer killed
> everything in sight, including X's console, making X exit, killing
> all remaining processes.
> 
> The new versions have been polished a little bit so as not to waste
> too much memory, and now survive the 30000 mount/umount test for me.
> Further polishing is needed for the case of large numbers of mounts;
> when /etc/mtab is not a symlink to /proc/mounts then umount -a has
> quadratic behaviour (it updates mtab after each unmount) and that
> gets terribly slow.
> 
> About OOM: I am still of the opinion that the default state of the
> kernel must be one where OOM does not occur and malloc() tells us
> that we are out of memory. A system that suddenly decides to kill
> all processes is really very poor and unreliable.
> Users can enable other behaviours if they don't care about reliability.
> 
> About mount: I wondered whether I should rewrite [u]mounts's handling
> of /etc/mtab so as to be a bit faster. But it seems a waste of time -
> /proc/mounts has many advantages: automatically up-to-date, correct
> also when namespaces are used, much faster. On the other hand, /etc/mtab
> contains mount options that are sometimes needed later.
> If it were possible to store the mount options in the kernel, making
> them visible in /proc/mounts, then we could forget /etc/mtab altogether.
> 
> People have asked repeatedly for a way to mark lines in /etc/fstab
> so as to make clear that such lines are managed by some GUI or other
> external program. Labels like "kudzu".
> In this release I added a comment convention for /etc/fstab: options
> can have a part starting with \; - that part is ignored by mount
> but can be used by other programs managing fstab.
> 
> If we would put the mount options in /proc/mounts, and introduced
> a comment convention (say, the part starting with \: is ignored by
> the kernel but can be used by programs reading /proc/mounts),
> then /etc/mtab can die. Comments? Better solutions?
> 
> About util-linux and stuff: I have maintained various packages
> for ten years or so - it may be time to pass things on to someone else.
> Write to aeb AT cwi.nl if you are interested in taking over or
> co-maintaining kbd or man or man-pages or util-linux.
> 
> Andries
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo AT vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> ----- End forwarded message -----
> 
> 
> --
> Eric Sandall                     |  Source Mage GNU/Linux Developer
> eric AT sandall.us PGP: 0xA8EFDD61  |  http://www.sourcemage.org/
> http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
> http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> 

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org