1 |
On 26/01/2012 13:30, Todd Goodman wrote: |
2 |
> * Joakim Tjernlund<joakim.tjernlund@×××××××××.se> [120126 05:38]: |
3 |
> [..] |
4 |
>> When you update the RO layer you will be back to a single copy, the previous |
5 |
>> release which is only in the overlay is gone, right? |
6 |
> That's up to you. You can manage your updates however you want. For |
7 |
> example, you can have your RO layer loop mounted out of a release image |
8 |
> and have two (or more) different RW areas depending on which image |
9 |
> you're running. That can allow you to fallback from an update fairly |
10 |
> easily. |
11 |
|
12 |
Indeed. |
13 |
|
14 |
So for example I am trying something a bit like the Slax distro: |
15 |
- I produce a base distro that will hopefully change very slowly. This |
16 |
has the minimal software for any other base (uclibc, busybox, few tools ...) |
17 |
- I produce a faster moving update that has real software on it (eg I |
18 |
need Dovecot/Postfix, some other stuff) |
19 |
- I have a final overlay with "my" software on, ie integration stuff |
20 |
(this is the web apps, very specific stuff to this build, etc. note |
21 |
this may turn out to be a wrong move - considering combining this with |
22 |
the step above...) |
23 |
- I bind mount some other stuff over the top of this, eg my kernel |
24 |
/lib/modules is in a squashfs and bind mounted into this. Therefore I |
25 |
can update the kernel separately to all of the above. |
26 |
|
27 |
|
28 |
The goal of this chain was to minimise the *size* of updates. Your goal |
29 |
might be different and hence have fewer/more layers. I also considered |
30 |
the possibility of "shims" between the faster moving layers above. The |
31 |
motivation was to be able to do little micro updates without rebuilding |
32 |
a whole layer (my layers are perhaps 10MB+ and the users have expensive |
33 |
and slow bandwidth, so being able to ship a 50KB shim to fix something |
34 |
is better than a 10MB module - not convinced yet, but sharing the idea...) |
35 |
|
36 |
Don't feel this is right for you. Just highlighting how you could use |
37 |
an overlay filesystem. Also see the Slax distribution for an example |
38 |
which takes this to extremes (software installs are just overlay modules |
39 |
to a basic core system - very clever) |
40 |
|
41 |
Good luck |
42 |
|
43 |
Ed W |