Regarding stability: http://www.squid-cache.org/mail-archive/squid-users/201202/0356.html Regarding writes in aufs: In the unmodified source code of 2.7, they are sync. Ref. to /squid/squid-2.7.STABLE9-20110824/src/fs/aufs/store_asyncufs.h /* Which operations to run async */ #define ASYNC_OPEN 1 #define ASYNC_CLOSE 0 #define ASYNC_CREATE 1 #define ASYNC_WRITE 0 #define ASYNC_READ 1 However, during real execution, the behaviour of LINUX disk subsystem will come into effect: The deferred writes. Actually, this is a grey area to me. Because so many parameters, also depending upon kernel version . Looking into this in more detail, I must clarify my statement, that "writes using aufs are sync": "In the unmodified source code of squid 2.7 aufs performes only async reads, file opens and file creates. However, because of the underlying disk subsystem used in LINUX, writes will in essence be executed async as well." (Which might also explain the #define ASYNC_WRITE 0 ??) After rethinking my previous post then, this leads me to the consequence, to agree, that probably aufs will in fact is the faster solution in LINUX in all scenarious, because also the async (coded) writes of diskd finally will depend executionwise upon the same underlying disk subsystem used. Sorry for the confusion. I have no benchmarks; because of my saturated disks, I simply looked into ways to tune squid a bit. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Metrics-to-calculate-best-values-for-cache-mem-and-cache-dir-tp4508859p4511569.html Sent from the Squid - Users mailing list archive at Nabble.com.
