Attached is my quick and dirty hack to make rootfs be tmpfs when
CONFIG_TMPFS is
enabled. It can't be this easy or somebody would have done it in the
_eight_years_
since https://lkml.org/lkml/2006/7/31/145
Yes, it's got an #ifdef and out of place prototypes. Yes, it manually
calls a module
init function and compensates by making it reentrant. But it works, and
when I
"cat /dev/zero > filename" the filesystem fills _up_ instead of
panicing the kernel.
So now that I've posted the error, would someone please tell me how I
_should_ have done it?
Rob
P.S. If I actually change the filesystem type to a name other than
"rootfs", it panics on the way up because various bits of the kernel
are looking for that magic name. Sigh.
P.P.S. removing MS_NOUSER is actually intentional, there's a local cray
patch that does the same thing because otherwise you can't --bind mount
directories out of this filesystem, which is a thing they wanted to do.-
On 04/03/2013 07:30:08 AM, Rob Landley wrote:
> Attached is my quick and dirty hack to make rootfs be tmpfs when
> CONFIG_TMPFS is
> enabled.
For a somewhat quantum definition of "attached".
Rob
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).
See attached.
-Byron
On Wed, 3 Apr 2013, Rob Landley wrote:
> Attached is my quick and dirty hack to make rootfs be tmpfs when CONFIG_TMPFS
> is
> enabled. It can't be this easy or somebody would have done it in the
> _eight_years_
> since https://lkml.org/lkml/2006/7/31/145
>
> Yes, it's got an #ifdef and out of place prototypes. Yes, it manually calls a
> module
> init function and compensates by making it reentrant. But it works, and when
> I
> "cat /dev/zero > filename" the filesystem fills _up_ instead of panicing the
> kernel.
>
> So now that I've posted the error, would someone please tell me how I
> _should_ have done it?
>
> Rob
>
> P.S. If I actually change the filesystem type to a name other than "rootfs",
> it panics on the way up because various bits of the kernel are looking for
> that magic name. Sigh.
>
> P.P.S. removing MS_NOUSER is actually intentional, there's a local cray patch
> that does the same thing because otherwise you can't --bind mount directories
> out of this filesystem, which is a thing they wanted to do.--
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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-
On 04/09/13 07:52, Rob Landley wrote:
> 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...
See include/linux/kconfig.h: IS_MODULE() and IS_BUILTIN().
>
> I'll poke at it.
--
~Randy
On Wed, Apr 03, 2013 at 07:30:08AM -0500, Rob Landley wrote:
> Attached is my quick and dirty hack to make rootfs be tmpfs when
> CONFIG_TMPFS is
> enabled. It can't be this easy or somebody would have done it in the
I don't see anything attached, but...
I have been running using tmpfs as my root for years. I tweaked the
debian initrd scripts to mount a tmpfs filesystem, cpio recover a
compressed cpio image from the disk drive and then pivotroot. Did not
require any kernel tweaks.
Thanks,
Robin
> _eight_years_
> since https://lkml.org/lkml/2006/7/31/145
>
> Yes, it's got an #ifdef and out of place prototypes. Yes, it
> manually calls a module
> init function and compensates by making it reentrant. But it works,
> and when I
> "cat /dev/zero > filename" the filesystem fills _up_ instead of
> panicing the kernel.
>
> So now that I've posted the error, would someone please tell me how
> I _should_ have done it?
>
> Rob
>
> P.S. If I actually change the filesystem type to a name other than
> "rootfs", it panics on the way up because various bits of the kernel
> are looking for that magic name. Sigh.
>
> P.P.S. removing MS_NOUSER is actually intentional, there's a local
> cray patch that does the same thing because otherwise you can't
> --bind mount directories out of this filesystem, which is a thing
> they wanted to do.--
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 04/09/2013 12:28:21 PM, Randy Dunlap wrote:
> On 04/09/13 07:52, Rob Landley wrote:
> > 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...
>
> See include/linux/kconfig.h: IS_MODULE() and IS_BUILTIN().
Good to know, thanks.
(It turns out I was looking at a distro kernel directory and vanilla
only lets TMPFS be static anyway, but I should still use that in case
it changes, and I think I still need to wire up a rootfsflags argument.)
Rob-
Rob Landley <rob <at> landley.net> writes:
> Attached is my quick and dirty hack to make rootfs be tmpfs when
> CONFIG_TMPFS is
> enabled. It can't be this easy or somebody would have done it in the
> _eight_years_
> since https://lkml.org/lkml/2006/7/31/145
Hi Rob,
We've been using a variation of the 2006 patch in TinyCore for years. It's
a fairly essential piece for us, as using it can save several seconds of
boot time for us.
Since we run in the initramfs, to get size limits and swappability, we used
to tar the files and switch_root. Both unnecessary steps when the kernel
could directly unpack to tmpfs.
So consider this a +1 "we use this".
- Lauri