All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rob Landley <rob@landley.net>,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, Jeff Layton <jlayton@redhat.com>,
	Jens Axboe <axboe@kernel.dk>, Jim Cromie <jim.cromie@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	Sam Ravnborg <sam@ravnborg.org>,
	Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs
Date: Thu, 18 Jul 2013 16:59:50 -0700	[thread overview]
Message-ID: <51E88176.6040505@zytor.com> (raw)
In-Reply-To: <20130717160602.4b225ac80b1cb6121cbb489c@linux-foundation.org>

On 07/17/2013 04:06 PM, Andrew Morton wrote:
> On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley <rob@landley.net> wrote:
> 
>> Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
>> Specify rootfstype=ramfs to get the old initramfs behavior.
>>
>> The previous initramfs code provided a fairly crappy root filesystem:
>> didn't let you --bind mount directories out of it, reported zero
>> size/usage so it didn't show up in "df" and couldn't run things like
>> rpm that query available space before proceeding, would fill up all
>> available memory and panic the system if you wrote too much to it...
> 
> The df problem and the mount --bind thing are ramfs issues, are they
> not?  Can we fix them?  If so, that's a less intrusive change, and we
> also get a fixed ramfs.
> 

mount --bind might be useful to fix for ramfs in general (as ramfs
should provide minimal standard filesystem functionality, and that one
counts, I believe), but honestly... we should have had tmpfs as a root
filesystem option either as rootfs or as an automatic overmount a long
time ago.

The automatic overmount option (that is tmpfs on top of rootfs) is nice
in some ways, as it makes garbage-collecting the inittmpfs trivial; this
might save some boot time in the more conventional root scenarios.  On
the other hand, it doesn't exactly seem to be a big problem to just
unlink everything.

	-hpa

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rob Landley <rob@landley.net>,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, Jeff Layton <jlayton@redhat.com>,
	Jens Axboe <axboe@kernel.dk>, Jim Cromie <jim.cromie@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	Sam Ravnborg <sam@ravnborg.org>,
	Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs
Date: Thu, 18 Jul 2013 16:59:50 -0700	[thread overview]
Message-ID: <51E88176.6040505@zytor.com> (raw)
In-Reply-To: <20130717160602.4b225ac80b1cb6121cbb489c@linux-foundation.org>

On 07/17/2013 04:06 PM, Andrew Morton wrote:
> On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley <rob@landley.net> wrote:
> 
>> Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
>> Specify rootfstype=ramfs to get the old initramfs behavior.
>>
>> The previous initramfs code provided a fairly crappy root filesystem:
>> didn't let you --bind mount directories out of it, reported zero
>> size/usage so it didn't show up in "df" and couldn't run things like
>> rpm that query available space before proceeding, would fill up all
>> available memory and panic the system if you wrote too much to it...
> 
> The df problem and the mount --bind thing are ramfs issues, are they
> not?  Can we fix them?  If so, that's a less intrusive change, and we
> also get a fixed ramfs.
> 

mount --bind might be useful to fix for ramfs in general (as ramfs
should provide minimal standard filesystem functionality, and that one
counts, I believe), but honestly... we should have had tmpfs as a root
filesystem option either as rootfs or as an automatic overmount a long
time ago.

The automatic overmount option (that is tmpfs on top of rootfs) is nice
in some ways, as it makes garbage-collecting the inittmpfs trivial; this
might save some boot time in the more conventional root scenarios.  On
the other hand, it doesn't exactly seem to be a big problem to just
unlink everything.

	-hpa


  parent reply	other threads:[~2013-07-18 23:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-10  2:06 [RESEND] The initmpfs patches Rob Landley
2013-07-15 21:01 ` Andrew Morton
2013-07-16 15:31   ` [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs Rob Landley
2013-07-16  4:07   ` [RESEND] The initmpfs patches Rob Landley
2013-07-16  7:12     ` Ramkumar Ramachandra
2013-07-16 23:43       ` Rob Landley
2013-07-17  7:02         ` Ramkumar Ramachandra
2013-07-16 15:31   ` [PATCH 3/5] initmpfs v2: Move rootfs code from fs/ramfs/ to init/ Rob Landley
2013-07-16 15:31   ` [PATCH 4/5] initmpfs v2: Make rootfs use tmpfs when CONFIG_TMPFS enabled Rob Landley
2013-07-17 23:06   ` [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs Andrew Morton
2013-07-17 23:06     ` Andrew Morton
2013-07-18  0:15     ` Hugh Dickins
2013-07-18  0:15       ` Hugh Dickins
2013-07-18 23:17       ` Rob Landley
2013-07-18 23:17         ` Rob Landley
2013-07-18 23:17         ` Rob Landley
2013-07-18 23:59     ` H. Peter Anvin [this message]
2013-07-18 23:59       ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2013-07-16 15:31 Rob Landley
2013-07-16 15:31 ` Rob Landley
2013-07-16 15:31 Rob Landley
2013-07-16 15:31 ` Rob Landley
2013-07-16 23:45 Rob Landley
2013-07-16 23:45 ` Rob Landley
2013-07-16 23:45 ` Rob Landley

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=51E88176.6040505@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughd@google.com \
    --cc=jim.cromie@gmail.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rob@landley.net \
    --cc=rusty@rustcorp.com.au \
    --cc=sam@ravnborg.org \
    --cc=swarren@nvidia.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.