On Jun 3, 2011, at 6:25 AM, Roch wrote: > > Edward Ned Harvey writes: >> Based on observed behavior measuring performance of dedup, I would say, some >> chunk of data and its associated metadata seem have approximately the same >> "warmness" in the cache. So when the data gets evicted, the associated >> metadata tends to be evicted too. So whenever you have a cache miss, >> instead of needing to fetch 1 thing from disk (the data) you need to fetch N >> things from disk (data + the metadata.) >> >> >> >> I would say, simply giving bias to the metadata would be useful. So the >> metadata would tend to stay in cache, even when the data itself is evicted. >> Useful because the metadata is so *darn* small by comparison with the actual >> data... It carries a relatively small footprint in ram, but upon cache >> miss, it more than doubles the disk fetch penalty. >> >> >> >> If you consider the extreme bias... If the system would never give up >> metadata in cache until all the cached data were gone... Then it would be >> similar to the current primarycache=metadata, except that the system would >> be willing to cache data too, whenever there was available cache otherwise >> going to waste. >> >> > > Interesting. Now consider this : > > We have an indirect block in memory (those are 16K > referencing 128 individual data blocks). We also have an > unrelated data block say 16K. Neither are currently being > reference nor have they been for a long time (otherwise they > move up to the head of the cache lists). They reach the > tail of the primary cache together. I have room for one of > them in the secondary cache. > > Absent other information, do we think that the indirect > block is more valuable than the data block ? At first I also > wanted to say that metadata should be favored. Now I can't come > up with an argument to favor either one. Therefore I think > we need to include more information than just data vs > metadata in the decision process. > > Instant Poll : Yes/No ?
No. Methinks the MRU/MFU balance algorithm adjustment is more fruitful. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
