All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adriana Kobylak <anoo@linux.ibm.com>
To: openbmc@lists.ozlabs.org
Subject: Alternative to the filesystem overlay
Date: Thu, 15 Aug 2019 12:38:16 -0500	[thread overview]
Message-ID: <efb47539225e57a0ab0138987287c230@linux.vnet.ibm.com> (raw)

In OpenBMC we've been using an overlay to make the read-only filesystem 
(or part of it) writable. It hasn't come without its issues, like 
missing directories (openbmc/openbmc#3564) and various flavors of 
corruption (openbmc/openbmc#3578 and issues when adding files to /etc in 
the build causing files that had been previously modified on the bmc to 
become corrupted).

An alternative would be to use a bind mount and manage the file merging 
by an OpenBMC app. Doing some experimentation, seems this solves the 
issues seen above. The way that it'd work would be:
- The init script or initramfs would do an rsync from /etc to the bind 
mount destination directory in the read-write filesystem, skipping the 
contents of a list which would contain the files that have been modified 
in the BMC and should be preserved.
- A new OpenBMC app would monitor /etc for changes via inotify for 
example, and if a file is modified, it'd add it to the "list".

Considerations:
- The /etc dir mainly being a configuration destination does not get 
modified often so the app that is watching the directory would not be 
triggered often.
- The bind mount would duplicate the contents of etc although it's not 
much. If space is a concern, some exploration could be done to have the 
bind mount be a tmpfs and have the monitor app copy the modified files 
to the read-write filesystem instead of adding them to a list.

Thoughts?

             reply	other threads:[~2019-08-15 17:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 17:38 Adriana Kobylak [this message]
2019-08-15 18:43 ` Alternative to the filesystem overlay Andrew Geissler
2019-08-16  9:09 ` Alexander A. Filippov
2019-08-20 18:00   ` William Kennington
2019-08-21  7:28     ` Alexander A. Filippov
2019-08-21  0:56   ` Terry Duncan
2019-08-21  7:09     ` Alexander A. Filippov

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=efb47539225e57a0ab0138987287c230@linux.vnet.ibm.com \
    --to=anoo@linux.ibm.com \
    --cc=openbmc@lists.ozlabs.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.