- 11 Feb, 2011 2 commits
-
-
-
Poul-Henning Kamp authored
Fortunately there is a backstop, so worst case a request would just fail. Spotted by: Erik Missed by: phk, twice
-
- 10 Feb, 2011 2 commits
-
-
Ingvar Hagelund authored
-
Ingvar Hagelund authored
-
- 09 Feb, 2011 10 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Now it does.
-
Poul-Henning Kamp authored
The lock order is lru->exp lock, so that the timer_index can be safely examined while holding only the lru lock, eliminating the need for the separate OC_F_ONLRU flag. The critical trick is that in EXP_Touch() the lru_lock is sufficient: We just move the object around on the lru list, we don't add or delete it. This hopefully reduces lock contention on these locks.
-
Poul-Henning Kamp authored
process.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
whatever storage we have put the object into.
-
Poul-Henning Kamp authored
caught it, he would always say "Just checking if you were paying attention". I guess Erik Inge Bolsø was :-)
-
- 08 Feb, 2011 10 commits
-
-
Kristian Lyngstol authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
ones that later may find usage in a separate silo-maintenance utility.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Tollef Fog Heen authored
Experience shows that 2ms is a better value for thread_add_delay. This is high enough to prevent thread pileups and low enough that we do not run into as too few thread problems at startup.
-
- 07 Feb, 2011 11 commits
-
-
Poul-Henning Kamp authored
Commit the code that prevents all the evils mentionend in the previous commit message (see tests/p00007.vtc)
-
Poul-Henning Kamp authored
So imagine an object during fetch, where we have allocated the storage for the object structure, the persistent silo gets synced, so the data ends up in the next segment, and then we crash before that segment gets synched to silo. On restart the object looks good, until we try to access its storage... *bewm* This is a stopgap, that catches such objects and neuters them, using a set of paranoid sanitychecks we should employ in any case. There still is a relevant hole: As above, but after the restart we manage to write a new segment before the initial object is accessed, and it happens to have a storage structure just the same place (not unlikely at the beginning) We do not crash in this case, but deliver wrong content. Did I ever mention that -spersistent for all practical purposes is a filesytem ?
-
Poul-Henning Kamp authored
Remove the aim_nobj, it has been found not useful. Remove pointer from persistent.h, it shouldn't contain any. Document debug.persistent, it will be useful for debugging. Exercise it in testcase.
-
Poul-Henning Kamp authored
(via objcore method) and refer resultant empty persistant segments.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
it refers to.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
one segment open at a time anyway. Add a "sync" debug command
-
Poul-Henning Kamp authored
testing and debugging.
-
Poul-Henning Kamp authored
should be on.
-
Poul-Henning Kamp authored
Reminded about again by: Ralph Corderoy <ralph@inputplus.co.uk>
-
- 06 Feb, 2011 1 commit
-
-
Poul-Henning Kamp authored
actually makes sense... Spotted by: Ralph Corderoy <ralph@inputplus.co.uk>
-
- 03 Feb, 2011 4 commits
-
-
Ingvar Hagelund authored
from git.
-
Ingvar Hagelund authored
-
Tollef Fog Heen authored
Use strcmp and not == for comparing strings
-
Tollef Fog Heen authored
Typos in documentation, thanks to Camiel Dobbelaar for spotting these.
-