Full cache rebuild makes all contents MISS

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Delete swap* files
2.Start squid

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
lusca r14302, bsd72 i386

Please provide any additional information below.
@cache.log found lots of this
2009/09/24 04:00:38| tlv_unpack: insane length (194027304)!
2009/09/24 04:00:38| tlv_unpack: insane length (194027304)!
2009/09/24 04:00:38| tlv_unpack: insane length (194027304)!
2009/09/24 04:00:38| tlv_unpack: insane length (194027304)!
2009/09/24 04:00:38| tlv_unpack: insane length (194027304)!
2009/09/24 04:00:39| tlv_unpack: bad type (32)!
2009/09/24 04:00:39| tlv_unpack: overflow!
2009/09/24 04:00:39|    type=1, length=15872, buflen=1047, offset=1039
2009/09/24 04:00:39| tlv_unpack: bad type (32)!
2009/09/24 04:00:39| tlv_unpack: overflow!
2009/09/24 04:00:39|    type=1, length=15872, buflen=1047, offset=1039
2009/09/24 04:00:39| tlv_unpack: bad type (32)!
2009/09/24 04:00:39| tlv_unpack: overflow!

workaround... full rebuild using cacheboy then lusca

Original issue reported on code.google.com by chudy.fernandez on 24 Sep 2009 at 3:41

[GoogleCodeExporter]

Ok. I really, really need to make sure I understand this issue here. If I had 
to take
a stab at it, I'd say it has to do with the way I tidied up the rebuilding code 
and
I've somehow stuffed up the 32/64 (normal, large file) support.

I've got a FreeBSD-7.2 i386 box here. Can you please give me your config file 
and
"uname -a" output?

Thanks!

Original comment by adrian.c...@gmail.com on 19 Oct 2009 at 7:02

• Changed state: Accepted
• Added labels: Priority-High, Version-Head
• Removed labels: Priority-Medium, Version-1.0

[GoogleCodeExporter]

I just can't reproduce this weirdness on any of my FreeBSD boxes - and I've 
tried amd64/i386 for FreeBSD-7.2, 
7.x, 8.0. The rebuild log just seems to work. I can't figure out which 
combination of things doesn't wrok.

Are you able to still reproduce it? If so, may I please have access to some 
hardware which exhibits this?

Original comment by adrian.c...@gmail.com on 19 Jan 2010 at 9:01

[GoogleCodeExporter]

Is this still a problem Chudy?

Original comment by adrian.c...@gmail.com on 26 Mar 2010 at 1:57

[GoogleCodeExporter]

I'm not sure...
but here's the content
{{{http://photos-b.ak.fbcdn.net/hphotos-ak-snc3/hs371.snc3/23844_1250277941065_1
352993179_604404_6260611_n.jpg}}}
headers according to redbot.org
 HTTP/1.1 200 OK
    Content-Type: image/jpeg
    Last-Modified: Tue, 01 Jan 2008 00:00:00 GMT
    X-Haystack-Error: HS_ESUCCESS
    X-Haystack-Error-String: Operation succeeded
    Content-Length: 86752
    Cache-Control: max-age=31426861
    Expires: Fri, 25 Mar 2011 22:54:00 GMT
    Date: Sat, 27 Mar 2010 05:12:59 GMT
    Connection: keep-alive
After rebuild:
access.log shows TCP_REFRESH_MISS

...and cache.log still flooded with this:
2010/03/27 12:08:38| tlv_unpack: unable to unpack: passed buffer size 476160 
bytes; TLV length 33751554 bytes; header prefix size 5 
bytes

Original comment by chudy.fernandez on 27 Mar 2010 at 5:23

[GoogleCodeExporter]

Is this with COSS, or just AUFS?

Original comment by adrian.c...@gmail.com on 27 Mar 2010 at 5:59

[GoogleCodeExporter]

tested both. then tested on AUFS only. same flood and same TCP_REFRESH_MISS.

Original comment by chudy.fernandez on 27 Mar 2010 at 6:17

[GoogleCodeExporter]

ok. We're going to have to leave that until the rebuild stuff has been verified 
as
fixed. This looks like a separate issue.

Let me go and write a cache object inspection tool. I need to see what the data 
in
the actual swap file is so I can try to figure out why it's being read in that
corrupted fashion.

Original comment by adrian.c...@gmail.com on 27 Mar 2010 at 10:16

[GoogleCodeExporter]

I've committed the inspection tool. Chudy is now running it over his cache to 
see
whether it picks anything up.

Original comment by adrian.c...@gmail.com on 29 Mar 2010 at 10:11