搜索了一下似乎没有多少人使用squid coss,我做个开路先锋

qq830406

cache_dir coss /squid1 256 block-size=512 max-size=131072
cache_dir coss /dev/sdf1 34500 max-size=524288 max-stripe-waste=32768 block-size=4096 maxfullbufs=10

squid26

转载的资料

8.6 coss存储机制

循环目标存储机制（Cyclic Object Storage Scheme,coss）尝试为squid定制一个新的文件系统。在ufs基础的机制下，主要的性能瓶颈来自频繁的open()和unlink()系统调 用。因为每个cache响应都存储在独立的磁盘文件里，squid总是在打开，关闭，和删除文件。

与之相反的是，coss使用1个大文件来存储所有响应。在这种情形下，它是特定供squid使用的，小的定制文件系统。coss实现许多底层文件系统的正常功能，例如给新数据分配空间，记忆何处有自由空间等。

不幸的是，coss仍没开发完善。coss的开发在过去数年里进展缓慢。虽然如此，基于有人喜欢冒险的事实，我还是在这里描述它。


8.6.1 coss如何工作

在磁盘上，每个coss cache_dir是一个大文件。文件大小一直增加，直到抵达它的大小上限。这样，squid从文件的开头处开始，覆盖掉任何存储在这里的数据。然后，新的目标总是存储在该文件的末尾处。

squid实际上并不立刻写新的目标数据到磁盘上。代替的，数据被拷贝进1MB的内存缓冲区，叫做stripe。在stripe变满后，它被写往磁盘。coss使用异步写操作，以便squid主进程不会在磁盘I/O上阻塞。

象其他文件系统一样，coss也使用块大小概念。在7.1.4章里，我谈到了文件号码。每个cache目标有一个文件号码，以便squid用于定 位磁盘中的数据。对coss来说，文件号码与块号码一样。例如，某个cache目标，其交换文件号码等于112，那它在coss文件系统中就从第112块 开始。因此coss不分配文件号码。某些文件号码不可用，因为cache目标通常在coss文件里占用了不止一个块。

coss块大小在cache_dir选项中配置。因为squid的文件号码仅仅24位，块大小决定了coss缓存目录的最大size：size = 块大小 x (2的24次方)。例如，对512字节的块大小，你能在coss cache_dir中存储8GB数据。

coss不执行任何squid正常的cache置换算法（见7.5章）。代替的，cache命中被"移动"到循环文件的末尾。这本质上是LRU算法。不幸的是，它确实意味着cache命中导致磁盘写操作，虽然是间接的。

在coss中，没必要去删除cache目标。squid简单的忘记无用目标所分配的空间。当循环文件的终点再次抵达该空间时，它就被重新利用。


8.6.2 编译和配置coss

为了使用coss，你必须在运行./configure时，在--enable-storeio列表里增加它：
% ./configure --enable-storeio=ufs,coss ...

coss缓存目录要求max-size选项。它的值必须少于stripe大小（默认1MB，但可以用--enable-coss-membuf-size选项来配置）。也请注意你必须忽略L1和L2的值，它们被ufs基础的文件系统使用。如下是示例：

cache_dir coss /cache0/coss 7000 max-size=1000000
cache_dir coss /cache1/coss 7000 max-size=1000000
cache_dir coss /cache2/coss 7000 max-size=1000000
cache_dir coss /cache3/coss 7000 max-size=1000000
cache_dir coss /cache4/coss 7000 max-size=1000000

甚至，你可以使用block-size选项来改变默认的coss块大小。
cache_dir coss /cache0/coss 30000 max-size=1000000 block-size=2048

关于coss的棘手的事情是，cache_dir目录参数（例如/cache0/coss）实际上不是目录，它是squid打开或创建的常规文件。所以你可以用裸设备作为coss文件。假如你错误的创建coss文件作为目录，你可以在squid启动时见到如下错误：

2003/09/29 18:51:42| /usr/local/squid/var/cache: (21) Is a directory
FATAL: storeCossDirInit: Failed to open a coss file.

因为cache_dir参数不是目录，你必须使用cache_swap_log指令（见13.6章）。否则squid试图在cache_dir目录中创建swap.state文件。在该情形下，你可以见到这样的错误：

2003/09/29 18:53:38| /usr/local/squid/var/cache/coss/swap.state:
(2) No such file or directory
FATAL: storeCossDirOpenSwapLog: Failed to open swap log.

coss使用异步I/O以实现更好的性能。实际上，它使用aio_read()和aio_write()系统调用。这点也许并非在所有操作系统中 可用。当前它们可用在FreeBSD,Solaris,和Linux中。假如coss代码看起来编译正常，但你得到"Function not implemented"错误消息，那就必须在内核里激活这些系统调用。在FreeBSD上，必须在内核配置文件中有如下选项：
options VFS_AIO


8.6.3 coss发行

coss还是实验性的功能。没有充分证实源代码在日常使用中的稳定性。假如你想试验一下，请做好存储在coss cache_dir中的资料丢失的准备。 从另一面说，coss的初步性能测试表现非常优秀。示例请见附录D。

coss没有很好的支持从磁盘重建cache数据。当你重启squid时，你也许会发现从swap.state文件读取数据失败，这样就丢失了所有的缓存数据。甚至，squid在重启后，不能记忆它在循环文件里的位置。它总是从头开始。

coss对目标置换采用非标准的方式。相对其他存储机制来说，这可能导致命中率更低。

某些操作系统在单个文件大于2GB时，会有问题。假如这样的事发生，你可以创建更多小的coss区域。例如：
cache_dir coss /cache0/coss0 1900 max-size=1000000 block-size=128
cache_dir coss /cache0/coss1 1900 max-size=1000000 block-size=128
cache_dir coss /cache0/coss2 1900 max-size=1000000 block-size=128
cache_dir coss /cache0/coss3 1900 max-size=1000000 block-size=128

使用裸磁盘设备（例如/dev/da0s1c）也不会工作得很好。理由之一是磁盘设备通常要求I/O发生在512个字节的块边界（译者注：也就是块设备访问）。另外直接的磁盘访问绕过了系统高速缓存，可能会降低性能。然而，今天的许多磁盘驱动器，已经内建了高速缓存。

[ 本帖最后由 qq830406 于 2006-12-21 15:31 编辑 ]

本大王

请问  用这种存储机制 效果如何?