>> 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. When there is a crash, the time to rebuild the raid < 1min?
... >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? This is the idea, but when there is a fsync, it must be written to disk. Therefore there are small segments inside of one "physical segment" Also LFS is still far from being stable. >> 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. This one is the last point in my list, but this is the obvius adventage of any write cache
