linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: Thomas Capricelli <orzel@kde.org>, linux-kernel@vger.kernel.org
Subject: Re: Mounting a in-ROM filesystem efficiently
Date: Thu, 13 Dec 2001 14:41:05 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.3.95.1011213142534.1037A-100000@chaos.analogic.com> (raw)
In-Reply-To: <080d01c18407$4f741650$5601010a@prefect>

On Thu, 13 Dec 2001, Bradley D. LaRonde wrote:

> ----- Original Message -----
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> To: "Bradley D. LaRonde" <brad@ltc.com>
> Cc: "Thomas Capricelli" <orzel@kde.org>; <linux-kernel@vger.kernel.org>
> Sent: Thursday, December 13, 2001 1:34 PM
> Subject: Re: Mounting a in-ROM filesystem efficiently
> 
> 
> > On Thu, 13 Dec 2001, Bradley D. LaRonde wrote:
> > [SNIPPED...]
> >
> > > Sent: Thursday, December 13, 2001 1:02 PM Subject: Re: Mounting a in-ROM
> > > filesystem efficiently
> > >
> > >
> > > > Generally, ROM based stuff is compressed before being written to >
> > > NVRAM. It's uncompressed into a RAM-Disk and the RAM-Disk is mounted.  >
> > > > That way, you can use, say, 2 megabytes of NVRAM to get a 10 to 20 >
> > > megabyte root file-system. This also allows /tmp and /var/log to be >
> > > writable, which is a great help because the development environment >
> > > closely approximates the run-time environment.
> > >
> > > That's perfect if you have plenty of RAM to spare.
> > >
> >
> > Well RAM is a hell of a lot cheaper than NVRAM. If you don't have
> > the required RAM on your box, the hardware engineers screwed up
> > and have to be "educated" preferably with an axe in the parking-lot.
> 
> As I mentioned before, there may be other-than-cost considerations for
> choosing the amount of RAM on a box.  For example, low power consumption on
> portable devices.  For another example, a huge ROM database that doesn't
> need to be in RAM all at once.
> 
> Regards,
> Brad
> 

Then you make a block-device device-driver that extracts and uncompresses
each read from ROM/NVRAM upon demand. It pretends to write. The actual
data-storage device is still paged and it only writes to the caller's
buffer so it doesn't use any RAM for storage.

When writing the compressed NVRAM, one has to use only allocation-unit
sizes, which reduces the amount of compression possible. Basically,
if you have 2000 "blocks", you need to compress 2000 individual blocks
and keep an uncompressed list of each block offset somewhere. This
complication is one of the many reasons why the general solution
is to un-compress everything once into RAM on startup. 

There are many arguments, but I don't think power consumption is
one of them. Whatever they use for RAM on the palm machines allows
the machines to run a week on 4 'aa' -size batteries. Maybe they
grab kinetic energy from keystrokes using flea-generators ^;).

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
 Santa Claus is coming to town...
          He knows if you've been sleeping,
             He knows if you're awake;
          He knows if you've been bad or good,
             So he must be Attorney General Ashcroft.



  reply	other threads:[~2001-12-13 19:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-13 16:02 Mounting a in-ROM filesystem efficiently Thomas Capricelli
2001-12-13 16:22 ` Bradley D. LaRonde
2001-12-13 16:41   ` Thomas Capricelli
2001-12-13 17:10     ` Bradley D. LaRonde
2001-12-13 18:02       ` Richard B. Johnson
2001-12-13 18:14         ` Bradley D. LaRonde
2001-12-13 18:34           ` Richard B. Johnson
2001-12-13 18:52             ` Bradley D. LaRonde
2001-12-13 19:41               ` Richard B. Johnson [this message]
2001-12-13 20:09                 ` Bradley D. LaRonde
     [not found]                 ` <08d701c18412/mnt/tmp/sendmee91d2c0601010a@prefect>
2001-12-18  1:27                   ` Pavel Machek
2001-12-14 11:03     ` Catalin Marinas
2001-12-13 17:49   ` David Woodhouse
2001-12-13 18:06     ` Bradley D. LaRonde
2001-12-13 20:38 ` H. Peter Anvin
2001-12-13 20:52   ` Bradley D. LaRonde
2001-12-14  9:45 ` David Woodhouse
2001-12-14 15:27   ` Bradley D. LaRonde
2001-12-14 16:51   ` David Woodhouse
2001-12-14 17:02     ` Bradley D. LaRonde
2001-12-14 17:03     ` David Woodhouse
2001-12-14 17:12       ` Bradley D. LaRonde
2001-12-14 17:16       ` David Woodhouse
2001-12-14 17:27         ` Bradley D. LaRonde
2001-12-16  9:51     ` Christoph Rohland
2002-01-23  8:01     ` Eric W. Biederman
     [not found] <20011214072540.D7457@duron.intern.kubla.de>
2001-12-17 13:24 ` Richard B. Johnson
2001-12-18 12:10   ` Helge Hafting
2001-12-18 14:00     ` Richard B. Johnson
2001-12-18 14:09       ` Alan Cox
2001-12-18 15:21         ` Mr. James W. Laferriere
2001-12-18 20:56         ` H. Peter Anvin
2001-12-18 16:27       ` Kent Borg
2001-12-18 17:05       ` Herman Oosthuysen

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=Pine.LNX.3.95.1011213142534.1037A-100000@chaos.analogic.com \
    --to=root@chaos.analogic.com \
    --cc=brad@ltc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=orzel@kde.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;
as well as URLs for NNTP newsgroup(s).