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 ?

-r

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to