On Thu, Feb 21, 2013 at 3:46 AM, Matias Bjorling <m...@itu.dk> wrote: > Recent development in Linux SSD caches, uses a block IO approach to solve > caching. The approach assumes that data is stable on disk and evicts data > based > on LRU, temparature, etc. This is great for read only IO patterns and in-place > writes. However, btrfs uses a copy on write approach, that reduces the > benefits > of block IO caching. The block caches are unable to track updates (require > extensive hints forth and back between the cache layer). Additionally, data > and > metadata is the same to the block layer.
Another great reason for this to be implemented in btrfs is that knowledge of redundancy can be applied. Chunks that are mirrored should be unlikely to need both copies on SSD devices unless they are very highly used (probably true for some of the meta data but not for data). Conversely there is little benefit to putting one stripe of a raid0/5/6 into the SSD device without the rest of that data reaching the same level. Not that additional reasons to do this work in btrfs were needed it does need to be thought about how this implementation interacts with those features. -- Gareth Pye Level 2 Judge, Melbourne, Australia Australian MTG Forum: mtgau.com gar...@cerberos.id.au - www.rockpaperdynamite.wordpress.com "Dear God, I would like to file a bug report" -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
