<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    Hm. What array does itself this time?<br>
    <br>
    26.02.16 0:44, Heiler Bemerguy пишет:<br>
    <span style="white-space: pre;">><br>
      > Since it started with both cache_dirs...<br>
      ><br>
      ><br>
      > Em 25/02/2016 15:32, Yuri Voinov escreveu:<br>
      >><br>
      > Don't think so.<br>
      ><br>
      > This messages floods all time?<br>
      ><br>
      > 26.02.16 0:17, Heiler Bemerguy пишет:<br>
      ><br>
      ><br>
      >       > I waited squid -z to finish.. did a "ps auxw |grep
      squid" a<br>
      >       dozen times to check.. THEN I started it.<br>
      ><br>
      >       > It may have tried to serve something, as lots of
      users we're<br>
      >       already conecting to it right after it started, but I'm
      still<br>
      >       seeing a flood of warnings on error.log:<br>
      ><br>
      ><br>
      ><br>
      ><br>
      ><br>
      >       > /2016/02/25 15:06:38 kid1| WARNING: swapfile
      header<br>
      >       inconsistent with available data//<br>
      ><br>
      >       > //2016/02/25 15:06:38 kid1| WARNING: swapfile
      header<br>
      >       inconsistent with available data//<br>
      ><br>
      >       > //2016/02/25 15:06:38 kid1| WARNING: swapfile
      header<br>
      >       inconsistent with available data//<br>
      ><br>
      >       > //2016/02/25 15:06:39 kid1| WARNING: swapfile
      header<br>
      >       inconsistent with available data/<br>
      ><br>
      ><br>
      ><br>
      >       > It's curious that with only one cache_dir (the
      first one), I<br>
      >       didn't receive any of these errors...<br>
      ><br>
      >       > Maybe the non-rounded "4097" value is causing an
      issue?<br>
      ><br>
      ><br>
      ><br>
      >       > Best Regards,<br>
      ><br>
      ><br>
      ><br>
      >       > --<br>
      ><br>
      >       > Heiler Bemerguy - (91) 98151-4894<br>
      ><br>
      >       > Assessor Técnico - CINBESA (91) 3184-1751<br>
      ><br>
      ><br>
      ><br>
      ><br>
      ><br>
      >       > Em 25/02/2016 14:18, Amos Jeffries escreveu:<br>
      ><br>
      >       >> On 26/02/2016 5:58 a.m., Heiler Bemerguy
      wrote:<br>
      ><br>
      >       >>> Hi Alex, Eliezer, Yuri, Amos..<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> So, to start from the start, after seeing
      squid was<br>
      >       totally stable and<br>
      ><br>
      >       >>> fast, running with NO cache_dirs, I tried
      to add only<br>
      >       2 rockstore<br>
      ><br>
      >       >>> cache_dirs to test.<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> conf:<br>
      ><br>
      >       >>> /cache_dir rock /cache2/rock1 20000
      min-size=0<br>
      >       max-size=4096<br>
      ><br>
      >       >>> slot-size=2048//<br>
      ><br>
      >       >>> //cache_dir rock /cache2/rock2 30000
      min-size=4097<br>
      >       max-size=16384<br>
      ><br>
      >       >>> slot-size=4096/<br>
      ><br>
      >       >>> (ps.: I know it would be nice to use one
      store PER<br>
      >       partition/disk/lun<br>
      ><br>
      >       >>> whatever.. but I'm trying to lessen disk
      wasting by<br>
      >       using small<br>
      ><br>
      >       >>> slot-sizes for small files.. am I wrong?)<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> Then squid -z:<br>
      ><br>
      >       >>> /2016/02/25 13:42:00 kid2| Creating Rock
      db:<br>
      >       /cache2/rock1/rock//<br>
      ><br>
      >       >>> //2016/02/25 13:42:00 kid3| Creating Rock
      db:<br>
      >       /cache2/rock2/rock/<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> Then running squid for the first time with
      these<br>
      >       newly created rock<br>
      ><br>
      >       >>> stores....<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> /2016/02/25 13:42:09 kid3| Loading
      cache_dir #1 from<br>
      >       /cache2/rock2/rock//<br>
      ><br>
      >       >>> //2016/02/25 13:42:09 kid2| Loading
      cache_dir #0 from<br>
      >       /cache2/rock1/rock//<br>
      ><br>
      >       >>> //2016/02/25 13:42:09 kid3| Store
      rebuilding is 0.01%<br>
      >       complete//<br>
      ><br>
      >       >>> //2016/02/25 13:42:09 kid2| Store
      rebuilding is 0.01%<br>
      >       complete/<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> Rebuilding what? just creating the huge
      files I<br>
      >       think...<br>
      ><br>
      >       >> The cache index for those rock DB.<br>
      ><br>
      >       >><br>
      ><br>
      >       >> Unlike UFS which stores a swap.state file,
      rock rebuilds<br>
      >       its index on<br>
      ><br>
      >       >> each startup.<br>
      ><br>
      >       >><br>
      ><br>
      >       >>> Then:<br>
      ><br>
      >       >>> /2016/02/25 13:42:19 kid1| WARNING:
      swapfile header<br>
      >       inconsistent with<br>
      ><br>
      >       >>> available data<br>
      ><br>
      >       >>> 2016/02/25 13:42:21 kid2| WARNING:
      cache_dir[0]:<br>
      >       Ignoring malformed<br>
      ><br>
      >       >>> cache entry meta data at 6943832064<br>
      ><br>
      >       >> <snip repeats><br>
      ><br>
      >       >>> 2016/02/25 13:42:40 kid1| ctx: enter
      level  0:<br>
      ><br>
      >       >>><br>
      >
'<a class="moz-txt-link-freetext" href="http://static.bn-static.com/pg/0plcB0QjJpBbwN7rMMDjKKO5Z63Nhu3zfPw==.gif">http://static.bn-static.com/pg/0plcB0QjJpBbwN7rMMDjKKO5Z63Nhu3zfPw==.gif</a>'<br>
      ><br>
      >       >>> 2016/02/25 13:42:40 kid1| WARNING:
      swapfile header<br>
      >       inconsistent with<br>
      ><br>
      >       >>> available data<br>
      ><br>
      >       >>> 2016/02/25 13:42:40 kid2| WARNING:
      cache_dir[0]:<br>
      >       Ignoring malformed<br>
      ><br>
      >       >>> cache entry meta data at 19581075456<br>
      ><br>
      >       >>> 2016/02/25 13:42:41 kid2| WARNING:
      cache_dir[0]:<br>
      >       Ignoring malformed<br>
      ><br>
      >       >>> cache entry meta data at 19757760512<br>
      ><br>
      >       >>> 2016/02/25 13:42:43 kid2| Finished
      rebuilding storage<br>
      >       from disk.<br>
      ><br>
      >       >>> 2016/02/25 13:42:43 kid2|   10239992
      Entries scanned<br>
      ><br>
      >       >>> 2016/02/25 13:42:43 kid2|        14
      Invalid<br>
      >       entries.///<br>
      ><br>
      >       >>><br>
      ><br>
      >       >>> What entry? why malformed? Wasn't it just
      a empty<br>
      >       store?! it just<br>
      ><br>
      >       >>> created it.......<br>
      ><br>
      >       >>><br>
      ><br>
      >       >><br>
      ><br>
      >       >> Did you wait for the -z background processes
      to finish<br>
      >       creating the 50GB<br>
      ><br>
      >       >> of disk allocation before starting the main
      Squid process<br>
      >       ?<br>
      ><br>
      >       >><br>
      ><br>
      >       >> Are your workers trying to serve up traffic to
      or from<br>
      >       the cache before<br>
      ><br>
      >       >> the rebuild has completed?<br>
      ><br>
      >       >><br>
      ><br>
      >       >><br>
      ><br>
      >       >> As you can see from the log timestamps on
      startup it will<br>
      >       take ~30-60<br>
      ><br>
      >       >> sec for the rock caches of that size to be
      loaded in your<br>
      >       system.<br>
      ><br>
      >       >><br>
      ><br>
      >       >><br>
      ><br>
      >       >> Amos<br>
      ><br>
      >       >><br>
      ><br>
      >       >>
      _______________________________________________<br>
      ><br>
      >       >> squid-users mailing list<br>
      ><br>
      >       >> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      ><br>
      >       >>
      <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      ><br>
      ><br>
      ><br>
      ><br>
      ><br>
      ><br>
      >       > _______________________________________________<br>
      ><br>
      >       > squid-users mailing list<br>
      ><br>
      >       > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      ><br>
      >       > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      >><br>
      >><br>
      >><br>
      >> _______________________________________________<br>
      >> squid-users mailing list<br>
      >> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      >> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      > -- <br>
      > Heiler Bemerguy - (91) 98151-4894<br>
      > Assessor Técnico - CINBESA (91) 3184-1751<br>
      ><br>
      ><br>
      > _______________________________________________<br>
      > squid-users mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJWz0y5AAoJENNXIZxhPexGNWIIAMyIhCWXnFfmOxZUtViQGvqp
<br>
    SNgdjYHjc5yCBsu4IdjlUTeYxwtp/wmn8u4K934oM00kzHw1aAnMUHHc9sRkiNlj
<br>
    oWKfejsHCxlEZyhuIvJ6qlRE/+EkFW35/rubKxHYH22aQ/R9hQaeb+mCW847bSNu
<br>
    qOaKyPG6NUj9+mHxhdg86XhG946+JXSHg0ALQjIPYAfrLAKPLGnPrxwc9KxMCQyZ
<br>
    wfhCDA9rS9GqUF0bOfbeO26ruJt0Y0fXpaC3Uuh/TCCTQlvg5mHXsFgq13kDSJta
<br>
    QPdyDaB9mroq/twocn6fe0/J0gAwi29pXISF1AmkcKEdoyIViMix/fykarMm7l4=
<br>
    =86Sx
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>