From: <Andries.Brouwer@cwi.nl>
To: linux-kernel@vger.kernel.org
Subject: OOM & [OT] util-linux-2.12e
Date: Mon, 20 Sep 2004 00:05:02 +0200 (MEST) [thread overview]
Message-ID: <UTC200409192205.i8JM52C25370.aeb@smtp.cwi.nl> (raw)
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@cwi.nl if you are interested in taking over or
co-maintaining kbd or man or man-pages or util-linux.
Andries
next reply other threads:[~2004-09-19 22:05 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-19 22:05 Andries.Brouwer [this message]
2004-09-20 9:46 ` Olaf Hering
2004-09-20 10:12 ` Andreas Schwab
2004-09-20 10:54 ` DervishD
2004-09-20 11:43 ` Andreas Schwab
2004-09-20 11:51 ` Paulo Marques
2004-09-20 12:11 ` DervishD
2004-09-20 12:14 ` Andreas Schwab
2004-09-20 12:00 ` DervishD
2004-09-20 10:23 ` Roman Zippel
2004-09-20 10:56 ` Olaf Hering
2004-09-20 11:16 ` Roman Zippel
2004-09-20 11:26 ` Olaf Hering
2004-09-20 11:38 ` Roman Zippel
2004-09-20 11:50 ` Olaf Hering
2004-09-20 12:02 ` Roman Zippel
2004-09-20 12:07 ` Olaf Hering
2004-09-20 12:14 ` Roman Zippel
2004-09-20 12:19 ` Olaf Hering
2004-09-20 12:34 ` Roman Zippel
2004-09-20 12:38 ` Olaf Hering
2004-09-20 12:51 ` Andreas Schwab
2004-09-20 12:54 ` Olaf Hering
2004-09-20 13:19 ` CaT
2004-09-20 13:33 ` Andreas Schwab
2004-09-20 13:15 ` CaT
2004-09-20 10:59 ` DervishD
2004-09-20 13:24 ` Helge Hafting
2004-09-20 13:21 ` Olaf Hering
2004-09-20 13:32 ` Helge Hafting
2004-09-20 14:12 ` Herbert Poetzl
2004-09-21 7:20 ` Helge Hafting
2004-09-21 9:18 ` Herbert Poetzl
2004-09-20 15:24 ` Tonnerre
2004-09-20 11:11 ` David Gómez
2004-09-20 11:06 ` DervishD
2004-09-20 11:38 ` Xavier Bestel
2004-09-20 11:59 ` DervishD
2004-09-20 12:32 ` Xavier Bestel
2004-09-20 14:16 ` Herbert Poetzl
2004-09-21 16:45 ` Jari Ruusu
2004-09-21 21:26 ` Andries Brouwer
2004-09-22 17:05 ` Jari Ruusu
2004-09-22 18:39 ` Andries Brouwer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=UTC200409192205.i8JM52C25370.aeb@smtp.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome