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 t...@panix.com "The dirtiest word in art is the C-word. I can't even say 'craft' without feeling dirty." -Chuck Close