mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

             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