Re: What is the best layer/device for a write-back cache based in nvram?

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

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).