1 |
Joakim Tjernlund wrote: |
2 |
> > > You still want to pick a r/w branch with a filesystem that |
3 |
> > > handles power cuts well. You can continue to use JFFS2. |
4 |
> > |
5 |
> > Thought: Is there any evidence that one modern filesystem is better |
6 |
> > than another with regards to sudden power removal? You probably |
7 |
> > need to speak to filesystem experts at this point and define the |
8 |
> > kind of thing you are trying to protect against? Sounds like you |
9 |
> > have raw flash storage here, so that constrains your choices |
10 |
> > somewhat? |
11 |
|
12 |
In fact, having "raw" flash storage is the *only* way to have *any* |
13 |
chance of completely reliable handling of power outage. |
14 |
|
15 |
|
16 |
> AFAIK, only FSes which are designed for flash(JFFS2, UBIFS, YAFFS etc. ) |
17 |
> are safe w.r.t power cuts. |
18 |
|
19 |
It's not only about the filesystem, it is also critical that the |
20 |
kernel is actually in charge of writing to flash. This means that |
21 |
if you are not using an mtd based device, you can never have perfect |
22 |
reliability, regardless of what your filesystem promises. |
23 |
|
24 |
|
25 |
> We are not using NAND flash yet but our next product will. |
26 |
|
27 |
NAND or NOR is not important - mtd block device is. |
28 |
|
29 |
|
30 |
> I do have the impression that any block emulating device such as |
31 |
> SSD are unreliable w.r.t power cuts. I would love to be proven |
32 |
> wrong though :) |
33 |
|
34 |
Supposedly, Intel SSDs never report write completed before flash has |
35 |
actually been updated. Good luck verifying that. |
36 |
|
37 |
Everyone else buffers writes. The Samsung 830 series has 256MB of |
38 |
SDRAM, and their multicore ARM controller handles the magic |
39 |
buffering. Samsung 830 is built entirely by Samsung from Samsung |
40 |
parts. All manufacturers besides Intel and Samsung use a mishmash |
41 |
of components and firmware in their SSD products, and all do magic |
42 |
buffering. |
43 |
|
44 |
|
45 |
//Peter |