Re: Disk Cache Patch

Here is how the same address is used. 

In LD_discover(), a local variable "working_disk" is used (repeatedly) to create new 
objects from a list of devices.

Then, get_geometry() is called, which in turn calls get_partition_table_geometry(), 
which calls LD_read(), which calls read_from_cache(). If no hit in read_from_cache(),
write_to_cache() will be called (afer a successful write). 

So the cache entries are identified by the address of "working_disk", which is the same
in consecutive calls inside LD_discover(). 


According to the log file, here is the when entries are created:

grep -n "Create a new cache entry for disk " evms-engine.2.log | head -3

10216:Jun 05 16:30:42 lab104 _8_ LocalDskMgr: write_to_cache: Create a new cache entry for disk cciss!c0d0, sector 0, count 1.
14314:Jun 05 16:30:42 lab104 _8_ LocalDskMgr: write_to_cache: Create a new cache entry for disk cciss/c0d0, sector 0, count 2.
14378:Jun 05 16:30:42 lab104 _8_ LocalDskMgr: write_to_cache: Create a new cache entry for disk cciss/c0d1, sector 0, count 2.

When entries are hit:

grep -n "read_from_cache: Read from cache." evms-engine.2.log | head -3

10371:Jun 05 16:30:42 lab104 _8_ LocalDskMgr: read_from_cache: Read from cache.  disk cciss!c0d1, sector 0, count 1.
10529:Jun 05 16:30:42 lab104 _8_ LocalDskMgr: read_from_cache: Read from cache.  disk cciss!c0d2, sector 0, count 1.
10691:Jun 05 16:30:42 lab104 _8_ LocalDskMgr: read_from_cache: Read from cache.  disk cciss!c0d3, sector 0, count 1.


Even though the addresses are not printed in the log, you can clearly see we hit 
disk "cciss!c0d1" in the cache at line 10371. Disk "cciss!c0d1" was never put
in the cache. Even disk "cciss/c0d1" was put in AFTER the bogus hit.


Hope this clear things up. 


Best regards,


- Changju

>>> Steve Dobbelstein <[email protected]> 6/12/2007 11:18 AM >>>

"Changju Gao" <[email protected]> wrote on 06/06/2007 11:30:21 AM:

> The local disk cache uses the address of an object as the
> identification for a cached entry.
> However, the addresses are not unique (in some cases). In our tests,
> the cache returned
> wrong data and caused serious problems.
>
> I changed the code to use the device major/minor number to identify
> cache entries.
>
> The attached patch fixes the problems we saw.
>
> Best regards,
>
>
> - Changju Gao

Hi, Changju.

Thanks for the patch.

I am curious how the address of the data structure for the disk is not
unique.  If the data structures for two different disks are at the same
address there would be many other serious problems.  In what situation did
you see that the addresses are not unique?

Steve D.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Evms-devel mailing list
[email protected]
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel