Gareth Pye wrote: > On Thu, Feb 21, 2013 at 3:46 AM, Matias Bjorling <mabj@xxxxxx> 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). On the other hand, there's the option of doing something that bcache has had on its roadmap for a while (but I'm not sure was ever implemented) by striping clean data and mirroring dirty data across the SSDs. The intent for bcache was to maximize both redundancy (for dirty data, which can't be regenerated) and space (for clean data, where if you lose some you can just shrug and say "oh well") in the case of one SSD failing. > 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. > Agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
