RaidF: FlashRaid - best solution for flash filesystems
- Divide your flash-based block device into >3 parts, for example let's use 12 sections.
- Raid5 (or Raid6 if you need more protection) them.
- use resulting block device as base for your filesystems/swap.
This way you can run without wear-levelling layer (which AFAIK can't work in general case, because you would need Size/blocksize bytes/nibbles of additional wear-resistant storage to keep statistics of your wear), AND you gain additional protection, for very little price ( less then 10% of your storage ).
Conventional wisdom says you shouldn't raid on single device, but since flash devices are not mechanical and don't suffer noticable seek penalty you can do this with very little loss of performance. If you'd do this in hardware inside your card, there would be no performance penalty.
Another problem is that raid5/raid6 are famouse for their poor write speed, but, since you're already writing whole blocks-at-a-time when dealing with flash devices, you're already paying the prices (writing block-at-a-time is the best case scenario for raid5/6, there's no need to recalculate checksums then)
- Effective protection for wear problems, plus additional protection for other block errors
- Very small price storage-wise (<10%)
- Very small performance penalty when you synchronise flash blocks with raid blocks (the penalty for writing less-then-block-at-a-time is already payed when dealing with flash, raid penalty is virtually non-existant then)
- Ideal for embedding in hardware, but doable on software-side
Note: it doesn't make much sense to use raid5 instead of raid4 in this case. And raid4e for double protection. TODO: implement RaidF as dm layer?
| RaidF: FlashRaid - best solution for flash filesystems | | 2007.09.09-22:26.00
