From: Rob Landley <rob@landley.net>
To: Byron Stanoszek <bstanoszek@comtime.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] rootmpfs
Date: Tue, 09 Apr 2013 09:52:08 -0500 [thread overview]
Message-ID: <1365519128.18069.55@driftwood> (raw)
In-Reply-To: <alpine.LNX.2.00.1304051547440.2314@winds.org> (from bstanoszek@comtime.com on Fri Apr 5 14:53:12 2013)
On 04/05/2013 02:53:12 PM, Byron Stanoszek wrote:
> Rob,
>
> FWIW I have a patch to do something like this. It even gives you a
> rdsize=xxx
> tunable kernel parameter that lets you specify the size of the tmpfs,
> which
> acts like the -osize= mount flag (so phrases like 100M or 20% works).
> So doing
> things like 'cat /dev/zero > filename' will not run you out of all
> available
> memory. (Note: If you don't specify rdsize= on the kernel command
> line, it will
> not convert rootfs to tmpfs).
In init/do_mounts.c the boot infrastructure already has kernel command
line options "rootflags=" and "rootfstype=", so the logical thing to do
is probably to hook those up to rootfs. (That way instead of special
casing a new option we use the existing tmpfs option parsing.)
The default tmpfs size is 50%, which solves the "trivial to exhaust
memory and panic a kernel running under rootfs" problem. Having one
tmpfs also fixes the case that multiple tmpfs mounts (for /home and
/var, for example,) have separate memory limits that don't coordinate
with each other, so if /home can use 30% and /var can use 30%, that's
60% plus whatever rootfs is already using, so you can easily squeeze
the kernel against the wall without meaning to. (Yes, you can make one
tmpfs mount and --bind mount from there to elsewhere, I've seen that
done. Having rootfs just _be_ tmpfs makes this much easier to track.)
> See attached.
You're not actually changing the type of rootfs, you're overmounting it
with a second filesystem instance. (Mine hasn't got a "change", it just
mounts it correctly the first time, and there's just one rootfs
instance.)
What _is_ wrong with my version is that if you select tmpfs as a module
bad things happen; it tries to use code that's not there. I dunno of an
#ifdef that distinguishes between module and builtin, so I think I have
to add another kconfig symbol...
I'll poke at it.
Rob
next prev parent reply other threads:[~2013-04-09 14:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 12:30 [RFC] rootmpfs Rob Landley
2013-04-03 12:32 ` Rob Landley
2013-04-05 19:53 ` Byron Stanoszek
2013-04-09 14:52 ` Rob Landley [this message]
2013-04-09 17:28 ` Randy Dunlap
2013-04-10 17:23 ` Rob Landley
2013-04-10 13:43 ` Robin Holt
2013-04-11 17:25 ` Lauri Kasanen
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=1365519128.18069.55@driftwood \
--to=rob@landley.net \
--cc=bstanoszek@comtime.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.