sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: Eric Sandall <eric AT sandall.us>
- To: sm-discuss <sm-discuss AT lists.ibiblio.org>
- Subject: [SM-Discuss] Fwd: OOM & [OT] util-linux-2.12e
- Date: Mon, 20 Sep 2004 08:20:26 -0700
Shall we update util-linux?
-sandalle
----- 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] Fwd: OOM & [OT] util-linux-2.12e,
Eric Sandall, 09/20/2004
-
Re: [SM-Discuss] Fwd: OOM & [OT] util-linux-2.12e,
Arwed von Merkatz, 09/21/2004
-
Re: [SM-Discuss] Fwd: OOM & [OT] util-linux-2.12e,
Arwed von Merkatz, 09/23/2004
- Re: [SM-Discuss] Fwd: OOM & [OT] util-linux-2.12e, Arwed von Merkatz, 09/23/2004
-
Re: [SM-Discuss] Fwd: OOM & [OT] util-linux-2.12e,
Arwed von Merkatz, 09/23/2004
-
Re: [SM-Discuss] Fwd: OOM & [OT] util-linux-2.12e,
Arwed von Merkatz, 09/21/2004
Archive powered by MHonArc 2.6.24.