From: Roman Khimov <roman@khimov.ru>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-devel@lists.openembedded.org,
OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [oe] RFC: Reference updater filesystem
Date: Tue, 24 Nov 2015 21:47:52 +0300 [thread overview]
Message-ID: <11874234.lUveKP5eiY@masala.hex> (raw)
In-Reply-To: <5654AC12.9060808@windriver.com>
В письме от 24 ноября 2015 12:27:30 пользователь Mark Hatle написал:
> On 11/24/15 12:05 PM, Roman Khimov wrote:
> > В письме от 24 ноября 2015 07:47:38 пользователь Mark Hatle написал:
> >> On 11/24/15 4:39 AM, Roman Khimov wrote:
> >>> В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
> >>>> 1. Use a separate partition for the configuration.
> >>>>
> >>>> a. The pro of this method is the partition is not touched during the
> >>>>
> >>>> update.
> >>>>
> >>>> b. The con of this method is the configuration is not directly in
> >>>>
> >>>> rootfs (example: /etc).
> >>>
> >>> That's the right solution, although to do it really right (at least IMO)
> >>> you need to implement the /usr merge [1] (and that's orthogonal to using
> >>> or not using systemd), which can also help you make your /usr read-only
> >>> (because that's just code and static data) with read-write / for user
> >>> data of various sorts.
> >>
> >> Why does merging /usr have anything to do with this? I've read the case
> >> for merging /usr and / and still don't understand why it "helps". The
> >> key is that if you have separate partitions for /usr and /, then you
> >> need to update both of them in sequence. Merging these two just seems
> >> like a lazy solution to people not wanting to deal with early boot being
> >> self-contained.
> >
> > It helps in that you can achieve a clear separation of your software and
> > users data (whatever that is, even if that's just some configuration
> > files) and only update your part (which is /usr).
>
> This can easily be archived using different partitions like /opt as well.
Usually it leads to more complicated partitioning and more complicated startup
(as well as update) procedure. Of course it can vary from system to system,
but in my experience /usr merge was exactly the thing needed to clearly
separate and simplify things. One way or another you want to have your code
and users data to be separated, /usr merge makes it quite simple.
> Bandwidth is a big deal in areas that are not serviced by anything but very
> GPRS or worse. So 100 MB is even too big in some cases. Cost is a factor
> as is overall bandwidth.
>
> Again, it depends on the product and what you are building if this matters.
>
> The point is we don't want to make some assumptions that preclude
> alternative implementations.
Sure.
--
http://roman.khimov.ru
mailto: roman@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
next prev parent reply other threads:[~2015-11-24 18:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 21:41 RFC: Reference updater filesystem Mariano Lopez
2015-11-24 6:06 ` Anders Darander
2015-11-24 18:39 ` [yocto] " Lopez, Mariano
2015-11-24 7:32 ` Randy Witt
2015-11-24 17:19 ` Lopez, Mariano
2015-11-24 10:39 ` [oe] " Roman Khimov
2015-11-24 13:47 ` Mark Hatle
2015-11-24 17:02 ` [yocto] " Lopez, Mariano
2015-11-24 17:13 ` Mark Hatle
2015-11-24 18:05 ` Roman Khimov
2015-11-24 18:27 ` Mark Hatle
2015-11-24 18:47 ` Roman Khimov [this message]
2015-12-03 16:45 ` Mariano Lopez
2015-12-06 11:34 ` Jens Rehsack
[not found] ` <60350861.Ng52JMGuMb@bancha.hex>
2015-11-24 16:30 ` Lopez, Mariano
2015-11-24 18:10 ` Roman Khimov
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=11874234.lUveKP5eiY@masala.hex \
--to=roman@khimov.ru \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox