<div><span class="gmail_quote">On 11/30/06, <b class="gmail_sendername">Jens Wilke</b> <<a href="mailto:jens.wilke@de.ibm.com">jens.wilke@de.ibm.com</a>> wrote:</span> 
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">- You don't keep track of I/O on the fly to the cache that is mapped<br>directly in cache_hit(). How do you make sure that this I/O is completed
<br>before you replace a cache block?</blockquote>
<div> </div>
<div>The previous I/O from cache hit and the later I/O for cache replacement should be queued in order on the cache block device - is this a safe assumption?</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">- The cache block index is hashed, this means the cache data blocks are not<br>clustered. I don't think you can solve this problem with a proper hash function.
<br>Perhaps you should consider a (B-)Tree structure for that.</blockquote>
<div> </div>
<div>The current hash algorithm does clustering to some extent by mapping consecutive blocks from the source device to consecutive blocks on the cache device. But I agree that more sophisticated algorithms can be studied.
</div>
<div> </div>
<div>Thanks a lot for the suggestions. I will try to incorporate them in the next patch.</div>
<div> </div>
<div>- Ming</div></div>