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

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Wed, Sep 14, 2016 at 03:16:13PM +0000, Eduardo Horvath wrote:
> On Wed, 14 Sep 2016, Edgar Fuß wrote:
> 
> > > 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.
> 
> Hm...  Maybe what you need to do is make the LFS segment the same size as 
> the RAID stripe, then mount LFS async so it only ever writes entire 
> segments....

You have essentially described exactly how Sprite LFS worked (I'll have to
dig out the source to see what it did about fsync().


-- 
  Thor Lancelot Simon	                                     tls%panix.com@localhost

    "The dirtiest word in art is the C-word.  I can't even say 'craft'
     without feeling dirty."	-Chuck Close