All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Laurentiu Palcu <laurentiu.palcu@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/5] Remove /var/cache from volatiles directory
Date: Mon, 04 Feb 2013 11:51:32 +0000	[thread overview]
Message-ID: <1359978692.14071.152.camel@ted> (raw)
In-Reply-To: <510F875B.9070903@intel.com>

On Mon, 2013-02-04 at 12:03 +0200, Laurentiu Palcu wrote:
> 
> On 02/04/2013 11:46 AM, Mike Looijmans wrote:
> > On 02/04/2013 10:26 AM, Laurentiu Palcu wrote:
> >> > Hi,
> >> >
> >> > Re-generating applications' cache every time the system is rebooted is not a
> >> > very efficient process for an embedded device. Usually, the cache directory is
> >> > used by applications to store data resulting from time consmuming I/O or
> >> > calculation. So, this patchset will take out /var/cache from tmpfs.
> > What if you have a READONLY rootfs? This patch will "break" those 
> > devices I think.
> > 
> > 
> 
> Not necessarily. We are trying to have all postinstalls run on host, so
> we don't have to do any postinstall activity on target. Any cache
> generated during postinstall, will be generated at do_rootfs time. Then,
> we can deploy the image with the cache already in place.
> 
> Also, on a RO rootfs, there is really no need to update the cache since
> the cached files do not really change. Hence, the cache created on host
> should, in theory, be valid.
> 
> If the above logic is missing anything, feel free to correct me.

If this is an issue and something does need to touch the cache
directory, we can mount a unionfs over /var/cache like we're doing
for /var/lib in the readonly rootfs patch series.

Ultimately, I think we're better served with that approach all round.

Cheers,

Richard




  reply	other threads:[~2013-02-04 12:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04  9:26 [PATCH 0/5] Remove /var/cache from volatiles directory Laurentiu Palcu
2013-02-04  9:26 ` [PATCH 1/5] base-files: remove /var/cache from volatiles Laurentiu Palcu
2013-02-04  9:26 ` [PATCH 2/5] fs-perms: " Laurentiu Palcu
2013-02-04  9:26 ` [PATCH 3/5] initscripts: " Laurentiu Palcu
2013-02-04  9:26 ` [PATCH 4/5] systemd: " Laurentiu Palcu
2013-02-04  9:26 ` [PATCH 5/5] rpm: remove /var/volatiles/cache/rpm from the FILEs list Laurentiu Palcu
2013-02-04  9:46 ` [PATCH 0/5] Remove /var/cache from volatiles directory Mike Looijmans
2013-02-04 10:03   ` Laurentiu Palcu
2013-02-04 11:51     ` Richard Purdie [this message]
2013-02-04 17:47     ` Phil Blundell
2013-02-04 17:51       ` Burton, Ross
2013-02-04 18:25         ` Enrico Scholz
2013-02-04 19:36           ` Burton, Ross
2013-02-05  2:37 ` ChenQi
2013-02-05  9:56   ` Laurentiu Palcu
2013-02-05 20:50 ` Saul Wold

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=1359978692.14071.152.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=laurentiu.palcu@intel.com \
    --cc=openembedded-core@lists.openembedded.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.