The cache_dir type in Squid has nothing to do with the underlying filesystem type, it defines the storage method / implementation. Currently Squid has 4 different implementations:
ufs :- On top of a normal filesystem supporting directories and files.
aufs :- As "ufs", but using threads to implement non-blocking disk I/O
diskd :- As "ufs", but using a separate process to implement non-blocking disk I/O
coss :- An experimental "raw" filesystem, where all objects are stored in one big file.
Other storage methods are being worked upon Kind of diskd is designed to work around the problem of blocking IO in a unix process. async ufs gets around this by using threads to complete disk IO. diskd uses external processes to complete disk IO. Asyncufs works just that little bit faster, but only works on systems where threads can do async disk IO without blocking the main process. Systems with user-threads (eg FreeBSD) can not use this effectively. Diskd, being implemented as an external process, gets around this. If cache is slightly active, then the difference cannot be noticed. diskd/aufs are only useful when the cache is under high load. In case it was not clear, asyncronous I/O (diskd/aufs) is beneficial for single drive configurations with "higher" request loads, in many cases allowing you to push about 100% more I/O thru the drive before latency creeps up too high. For multiple drive configurations, it is almost a requirement to be able to use the I/O capacity of the extra drives. Without it, a multiple disk configuration is effectively limited to almost the speed of a single disk configuration. With asyncronous I/O, the disk I/O scales quite well (at least for the first few drives, other limits gets very apparent when you have more than ~3 drives). |
