tis 2009-10-27 klockan 13:43 -0600 skrev Alex Rousskov:
Hi Henrik,
Can you explain what you mean by just ignore above? It is kind of
difficult for me to ignore the only code that seems to supply the info
Rock store needs. Do you mean we should ultimately remove STORE_META_STD
from
tis 2009-10-27 klockan 21:41 +0100 skrev Henrik Nordstrom:
Actual file storage size is more a business of the cache_dir than the
core..
Forgot to mention.. nothing stops a cache_dir implementation from
storing this attribute somehow associated with the data if one likes to,
but for cache_dirs
On 10/27/2009 02:46 PM, Henrik Nordstrom wrote:
tis 2009-10-27 klockan 21:41 +0100 skrev Henrik Nordstrom:
Actual file storage size is more a business of the cache_dir than the
core..
Forgot to mention.. nothing stops a cache_dir implementation from
storing this attribute somehow
On 10/27/2009 02:41 PM, Henrik Nordstrom wrote:
The object size field in STORE_META_STD should be ignored. Got broken
many years ago (1997 or so), and should be recalculated by using
STORE_META_OBJSIZE or alternatively the on-disk object size.
Rock code can ignore the swap_file_sz field stored
tis 2009-10-27 klockan 15:23 -0600 skrev Alex Rousskov:
Is not that always the case? Even if a store refuses to accept objects
larger than X KB, that does not mean that all objects will be X KB in
size, regardless of any reasonable X value. Or did you mean something
else by unbounded?
There
tis 2009-10-27 klockan 15:51 -0600 skrev Alex Rousskov:
To compute StoreEntry::swap_file_sz, I will add up the ported
STORE_META_OBJSIZE value and the swap_hdr_len set by StoreMetaUnpacker.
Would you compute it differently?
Sounds right to me.
What should I do if STORE_META_OBJSIZE is not
tis 2009-10-27 klockan 17:04 -0600 skrev Alex Rousskov:
On 10/27/2009 04:07 PM, Henrik Nordstrom wrote:
Thank you for porting this.
Was already done, just not sent yet.
Will you commit your changes to trunk?
Done.
Regards
Henrik
mån 2009-09-14 klockan 02:04 -0600 skrev Alex Rousskov:
Apparently, we are packing StoreEntry.swap_file_sz into the stored
entry header before we compute its value. This happens because to
compute swap_file_sz, we need to know swap_hdr_sz, the size of the
stored entry header. To compute
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just a small meta point: The new function you're adding looks like it
should be a method to me.
- -Rob
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org