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.ilReceived on Fri Nov 23 2012 - 02:49:50 MST
This archive was generated by hypermail 2.2.0 : Fri Nov 23 2012 - 12:00:08 MST