On 11/22/2012 10:35 AM, Henrik Nordström wrote:
ons 2012-11-21 klockan 21:06 +0200 skrev Eliezer Croitoru:
The problem is that it only being checked while a file is being fetched
from UFS(what I have checked) while from RAM it wont be checked.
There is no risk of object store displacement in RAM.
I think that 99% of the time you should not expect object store
displacement.
If we do suspect it then it should be tested while rebuilding the store.
the OS suppose to be very steady so
The result is that when store_url_rewrite feature is being used the
check points on inconsistency between the request url and the object in
cache_dir (naturally).
The metadata URL should be the store_url, not requested URL.
Of-course but the question is "to mess with it or not?"
I had a problem to make the needed data available such as a flag or
rewritten url at the step of the check since I kind of lost the scopes
of specific variables.
it seems to me like I should use some transit stage in the process.
After a small talk with alex I sat down and made some calculations about
MD5 collision risks.
The hash used to make the index hash is a string from "byte + url".
For most caches that I know of there is a very low probability for
collision considering the amount of objects and urls.
Verifying the MD5 is sufficient. But either MD5 or URL MUST be verified
in metadata on objects fetched from disk.
OK so MD5 is being checked and it's the store_url hash which I think how
it should be done by design.(and was done before)
Regards
Henrik
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
