I'm using a 12TB RAIDframe Level 5 RAID (4+1 discs) in production. There are 150 people's home directories and mail on FFFs file systems on it.
> 1- There is no need to use parity map for the RAID 1/10/5/6. Usually > the impact is small, but it can be noticeable in busy servers. I don't notice it. > 2- In scattered writes contained in a same slice, it allows to reduce > the number of writes. With RAID 5/6 there is a advantage, the parity > is written only one time for several writes in the same slice, instead > of one time for every write in the same slice. > 3- It allows to consolidate several writes that takes the full length > of the stripe in one write, without reading the parity. This can be > the case for log structured file systems as LFS, and allows to use a > RAID 5/6 with the similar performance of a RAID-0. You ought to adjust youd slice size and FS block size then, I'd suppose. I specifically don't get the LFS point. LFS writes in segments, which are rather large. A segment should match a slice (or a number of them) I would suppose LFS to perform great on a RAIDframe. Isn't Manuel Bouyer using this in production? > 4- Faster synchronous writes. Y E S. This is the only point I fully aggree on. We've had severe problems with brain-dead software (Firefox, Dropbox) performing tons of synchronous 4K writes (on a bs=16K FFS) which nearly killed us until I wrote Dotcache (http://www.math.uni-bonn.de/people/ef/dotcache) and we set XDG_CACHE_HOME to point to local storage. Woth WAPBL, there's also the journal (plus sync writes flushing it).