1 |
On 24/01/2012 14:06, Todd Goodman wrote: |
2 |
> * Joakim Tjernlund<joakim.tjernlund@×××××××××.se> [120124 02:18]: |
3 |
>> Ed W<lists@××××××××××.com> wrote on 2012/01/23 19:43:49: |
4 |
> [ .. ] |
5 |
>>> I'm doing something like this using aufs. The performance seems "not |
6 |
>>> bad", but you get a couple MB or so memory hit. (I'm using squashfs as |
7 |
>>> well, so unsure which causes the main memory increase). |
8 |
>> hmm, not sure how aufs would work out. One would like to permanently delete the |
9 |
> aufs is A Union FileSystem. You can have a RO "branch" (say SquashFS) |
10 |
> and a r/w "branch" (say JFFS2 or UBIFS.) When you write it will write |
11 |
> to the r/w branch and when you read it will read from the r/w branch if |
12 |
> it exists, else the r/o. |
13 |
> |
14 |
> So, if you want to permanently delete the old software. Write it to the |
15 |
> filesystem r/w filesystem (initially or after you have the aufs mounts |
16 |
> mounted.) Then you can delete from the r/w filesystem and it's gone for |
17 |
> good. |
18 |
|
19 |
Agreed. Just to augment that explanation: |
20 |
|
21 |
- The RO branch would be at the bottom (can be multiple of these) |
22 |
- The RW branch goes over the top (*can* be multiple of these, but one |
23 |
is more normal) |
24 |
- You can effectively delete stuff from the RO branches because Aufs has |
25 |
the concept of "white out" files. So for all intents and purposes the |
26 |
top RW layer can create any end result you like, including that of |
27 |
completely masking out some lower layer |
28 |
- With some knowledge of how the whiteout files work you can also "undo" |
29 |
changes to the RO files. Eg directly mounting the RW layer and erasing |
30 |
all files (from the RW layer) leaves you back with just the stacked RO |
31 |
layers again. I find this helpful for development where I can basically |
32 |
work live on the last released build and then by inspection the RW layer |
33 |
has all the changes needed to apply to the next RO layer release! |
34 |
|
35 |
I believe recent kernels also have a much simpler "Overlay Filesystem" |
36 |
that has fewer features. Also the big alternative to aufs is Unionfs 2 |
37 |
- most distros use aufs, but both seem viable? |
38 |
|
39 |
|
40 |
Finally note that you don't need to use aufs for the entire filesystem. |
41 |
A common setup might be to use a bunch of bind mounts where you know you |
42 |
don't need overlay features, eg /usr might be a bunch of overlays, /home |
43 |
might be a bind mount to writeable storage, /var might be a ram drive |
44 |
which is initialised from some fixed template, etc? In my case I have |
45 |
an overlay over most things, but /usr/lib/modules is a bind mount to a |
46 |
RO filesystem (you can't write to it), /home is mounted to my writeable |
47 |
storage (not layered), the main OS dirs are layered and /var is a mess... |
48 |
|
49 |
> You still want to pick a r/w branch with a filesystem that handles power |
50 |
> cuts well. You can continue to use JFFS2. |
51 |
|
52 |
Thought: Is there any evidence that one modern filesystem is better than |
53 |
another with regards to sudden power removal? You probably need to |
54 |
speak to filesystem experts at this point and define the kind of thing |
55 |
you are trying to protect against? Sounds like you have raw flash |
56 |
storage here, so that constrains your choices somewhat? |
57 |
|
58 |
Just note that with aufs you can use quite a few filesystems for the |
59 |
different layers. So for example you could have a base RW layer which |
60 |
is a DM snapshot, overlaid with a loopback mount to a DVD iso, overlay |
61 |
that with a squashfs, and finally overlay an Ext4 RW mount... (And of |
62 |
course each of the RO layers might be stored on varied filesystems |
63 |
themselves - check distributions such as Slax which allow you to overlay |
64 |
a squashfs that is itself inside some loopback mounted file...) |
65 |
http://aufs.sourceforge.net/aufs2/report/sq/ |
66 |
|
67 |
http://aufs.sourceforge.net/ |
68 |
|
69 |
I believe for most cheapo consumer flash storage where the underlying |
70 |
flash filesystem isn't exposed, its quite susceptable to *complete* |
71 |
failure with sudden poweroff? The issue is the invisible, underlying |
72 |
flash filesystem gets corrupted during a partial write and that can be |
73 |
the end of your flash drive - you don't even get to see it again to |
74 |
recover from it... I don't believe partitioning protects you from this, |
75 |
but of course separating read/write concerns to physically separate |
76 |
devices would help? I presume this isn't what you are using though? |
77 |
|
78 |
|
79 |
Good luck |
80 |
|
81 |
Ed W |