君，已阅读到文档的结尾了呢~~
Squid Coss文件系统技术分析 15：02From：现在很多公司都使用Squid作为Cache，Alibaba也不例外，这已经不是什么秘密了。Squid的COSS文件系统特别适合小文件的Cache，是很多公司存放小图片Cache的主要手段。今天翻电脑，找到早期写的一篇技术分析，供同学们参考，欢迎批评指正Squid COSS技术分析1 COSS机制分析1 1 COSS文件结构分析1 2 COSS的配置分析1 3 COSS Relocation机制2 COSS实现分析3 2 1 S..
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
Squid Coss文件系统技术分析
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口下次自动登录
现在的位置:
& 综合 & 正文
Squid Coss文件系统技术分析
现在很多公司都使用Squid作为Cache，Alibaba也不例外，这已经不是什么秘密了。Squid的COSS文件系统特别适合小文件的Cache，是很多公司存放小图片Cache的主要手段。
今天翻电脑，找到早期写的一篇技术分析，供同学们参考，欢迎批评指正
Squid COSS技术分析
1. COSS机制分析
1.1. COSS文件结构分析
1.2. COSS的配置分析
1.3. COSS Relocation机制
2. COSS实现分析 3
2.1. Squid FileSystem架构分析
2.2. COSS所使用的核心数据结构
2.2.1. SwapDir
2.2.2. struct _cossinfo
2.2.3. cossstripe
2.3. 关键流程分析
2.3.1. rebuild
2.3.2. Cache HIT时访问Object：storeCossOpen
3. 案例分析
3.1. 案例1
4. 关于使用COSS的建议
1. COSS机制分析
1.1. COSS文件结构分析
COSS文件是Squid专门开发的用于高效存储与管理小文件的应用层File System，全称是Cyclic Object Storage System。逻辑上，COSS文件被分为M+N个Stripe。Stripe是逻辑上COSS所使用的存储单元。在物理上，COSS由多个Stripe无缝串连拼凑起来。其中M指Memory形式的Stripe在硬盘上的映射所占的个数（配置项membufs所设置，默认为10个，表示本COSS文件支持10个内存stripe），N表示COSS剩余部分（Disk stripe）所可划分的最大Stripe数目。
逻辑上，COSS文件被形象的比做是一个“6”的样子，N个Disk Stripe组成一个环形，像是“6”的下部分，M个映射到Mem Stripe，像是“6”上面部分。
一个Stripe可以存放一个或多个Object，但每个Object不能跨越两个Stripe。这就决定了Stripe一旦固定，就不能存放比Stripe大的Object；也决定了，Stripe中几乎不可避免的有空间浪费。
此外，COSS文件物理上，将Stripe再分成Block，因此block大小一定要被stripe大小整除。使用Block的作Squid层物理IO接口的原因我想可能主要是：a) 与系统匹配，使利用OS的FileSytem以及物理Disk块的得以优化 b)Squid使用stripe号，以及fileno号来寻址Object，而fileno只有24位，因此，使用的block越大，COSS支持的文件就越大。
1.2. COSS的配置分析
从squid.conf来看，coss文件的典型配置如下：
cache_dir coss /data/cache1/coss0 34500 max-size=1000000 block-size=4096 overwrite-percent=50 membufs=10
其中，34500表示该COSS文件的最大大小是34.5G，max-size表示支持存储的最大Object大小，本质上就是Stripe的大小。Block-size表示每个物理存储块是4k。overwrite-percent表示当前stripe游标与该object原来存放地方的游标（Offset）之前的距离大于50%的整个COSS文件长度时，进行Relocation（文件搬移，后面详细说明），这个overwrite-percent一定要好好理解。
1.3. COSS Relocation机制
其实上，大家从测试中可以看到，Squid使用COSS时，即使在全Cache HIT的情况下，也会有大量的IO write操作。其根本就在于COSS的relocation机制。
本质上，Relocation是解决COSS文件的老化淘汰问题而引入的。因为COSS没有LRU或其它老化的根本原因是COSS无法实现随意的删除。Relocation是老化的一种变相实现。为什么这么说呢，要先分析一个COSS文件的使用机制。
上面提到，COSS的Disk Stripe是一个环形的，为了说明方便，我们假设将一个COSS文件的stripe编号为1,2,3…..N。COSS文件新建起来时，Squid会记录当前使用的Stripe号为1。同时，在系统维护一个stripe大小的内存块stripe-&membuf（默认是1M）。当有Object新建时，Squid将该Object的文件写到stripe-&membuf，当stripe-&membuf写满或不能容下新来的Object时，Squid会将该stripe交换(Swapout)到Disk上对应的stripe上。同时，将当前stripe指向2号stripe，并把新文件加到2号stripe-&membuf。同理，当２号stripe-&membuf满时，再swapout，并使用3号，依次类推。当整个COSS的Disk
stripe写满，则循环使用1号（这就是所谓的成环）。当前游标所到之处的stripe，则会被重写（覆盖）。
从这么看，似乎COSS与生俱来就有老化功能，为什么还要费力开发Relocation呢？我的理解是，当COSS文件的Object被删除时，如果不使用relocation就会引起COSS内部碎片严重，影响服务效果。
Relocaton是如何工作的？
当Squid访问Object时，首先会依据用户的配置(overwrite-percent)，判断该Object是否需要relocation。如果需要，则将该Object读出来之后，放到当前stripe-&membuf，待membuf写满后swapout到当前disk stripe。从而该Object就可以在最长的时间内保存在COSS文件中了（只到游标绕COSS一个圈，再次到达时，才会覆盖），从而实现了LRU类似的作用。
可以看到，由于Relocation的原因，本身只有Read操作的IO却增加了write操作，这是COSS的一个缺点。但COSS毕竟利用大文件来存储小文件，从而避免了AUFS频繁的Open、Close系统调用操作。但可以看到，使用COSS会增加io操作的次数，从而占用过多IOPS（read/write）。
2. COSS实现分析
2.1. Squid FileSystem架构分析
2.2. COSS所使用的核心数据结构
2.2.1. SwapDir
对应cache_dir的一行配置
struct _SwapDir {
const char *
int cur_ //本目录所有Object的大小的总和,以k为单位
int low_ //本目录由max_size及lowWaterMark算出来的low water字节数,kB
int max_ //本目录支持的最大使用字节数, kB
//本目录的路径
/* This entry’s index into the swapDirs array */
squid_off_t min_ //本目录支持的最小Object
squid_off_t max_ //本目录支持的最大Object
RemovalPolicy *
//本目录的老化策略handler
//FIXME:本参数没有使用
//FIXME:本参数没有使用
//当前Object选择存放到本目录时，设置为1,仅用于cachemgr
unsigned int selected:1;
//本目录在cache_dir配置中设置为read only
unsigned int read_only:1;
/* 以下为该FS对应的各操作函数指针 */
/* Initialise the fs */
STCHECKCONFIG * /* Verify configuration */
/* Create a new fs */
/* Dump fs config snippet */
/* Free the fs data */
STDBLCHECK * /* Double check the obj integrity */
STSTATFS *
/* Dump fs statistics */
STMAINTAINFS * /* Replacement maintainence */
STCHECKOBJ * /* Check if the fs will store an object */
STCHECKLOADAV * /* Check if the fs is getting overloaded .. */
/* These two are notifications */
STREFOBJ *
/* Reference this object */
STUNREFOBJ * /* Unreference this object */
STCALLBACK * /* Handle pending callbacks */
/* Sync the directory */
/* 以上为对本类FS的Object的操作函数 */
STOBJCREATE *
STOBJOPEN *
STOBJCLOSE *
STOBJREAD *
STOBJWRITE *
STOBJUNLINK *
STOBJRECYCLE *
/* 日志操作函数指针 */
STLOGOPEN *
STLOGCLOSE *
STLOGWRITE *
STLOGCLEANSTART *
STLOGCLEANNEXTENTRY *
STLOGCLEANWRITE *
STLOGCLEANDONE *
int writes_since_
//本文件系统的块大小
这是Squid FileSystem的一个抽象，对于每一个具体的实现，如COSS，则会利用利用自己的open, close, create等函数注册到这些API中。这种实现与Linux内核的Filesystem的实现方式一致。
某种意义上讲，我们可以基于这个抽象层自己开发适合自己业务的文件系统层。这就叫抽象层，叫接口层。是OS实现中重要的思想与技术。做过Linux内核开发的人应该很好理解。
2.2.2. struct _cossinfo
仅列出我们关心数据成员。
struct _cossinfo {
dlink_ //用link快速指向memory stripe
//一个快的指针，总是指向正在使用的Disk Stripe的membuf
struct _cossmembuf *current_
//指向整个COSS的当前offset，可能大于maxoffset
off_t current_
/* in bytes */
float minumum_overwrite_
//overwrite-percent的配置值
int minimum_stripe_ //由overwrite-percent计算的当前游标与Object原址所在施标大于distance时，就进行Object的搬迁，唯一用途在storeCossRelocateRequired的判断
//以下是Disk Stripes信息
//按COSS文件大小计算的，可以存的numstripes数
struct _cossstripe * //总大小是COSS文件支持的最大Disk stripe数，是一个以numstripes为下标的数组
//当前正在使用的stripe的号
int max_disk_
//等于coss文件的最大Block数
//以下是Memory Stripes信息
off_t current_memonly_
struct _cossmembuf *current_memonly_
//默认是10个，内存stripe的大小
//指向内存stripe，是一个指针数组,大小是nummemstripes
struct _cossstripe * //仅在storeCossMaybeFreeBuf时清除,是在writeMemBufDone时调用
//并不是内存stripe占用的数目，而是当前空闲使用的stripe
Cossinfo是每一个COSS文件对应一个，总体上记录COSS的各Stripe分配与映射。
特别注意成员cossinfo-&stripes，对于Disk Stripe，在程序初始化时，就将cossinfo-&stripes分配成一个numstripes大小（最大disk stripe数目）的数组。Cossinfo-&stripes[n]就分别对应这N个disk stripe。里面有足够的信息记录每一个disk stripe的使用情况。
另一个重要的成员是cossinfo-& memstripes。与Disk Stripe的实现与使用形式基本一致。
Squid就是利用这这个数据结构来管理整个COSS的，我们下面通过流程分析来理解。
2.2.3. cossstripe
struct _cossstripe {
//本stripe的object数目
int pending_
struct _cossmembuf * //正在写的object{s!} mem_buf,写满后同步到disk?
//本stripe中支持的objectslist，类型是StoreEntry。
2.3. 关键流程分析
2.3.1. rebuild
当rebuild时，Squid会依次打开每一个COSS文件，每读到一个stripe，不将该stripe的相关信息加入到cossinfo-&stripes[n]中，n是coss文件中逻辑的stripe块号。将该stripe的object信息读出后，放到cossinfo-&stripe[n]下，某个object信息则放到cossinfo-&stripe[n]-& objlist中。由于类型是StoreEntry，其中的其中的storeentry-&swap_filen与storeentry-&swap_dirn通过COSS一定的映射关系就可以算了来，在COSS文件的Offset，利用fseek就可以读取了。
简单的说，rebuild过程通过依次分析每一个stripe，将其中存在object信息还原到storeEntry的hash，以及cossinfo-&stripes[n]中，就完成了整个rebuild.
2.3.2. Cache HIT时访问Object：storeCossOpen
CossOpen的伪代码表示如下：
storeCossOpen（）
//在CossInfo的Mem Stripe找，看要访问的Object是否在Memory Stripe中
storeCossMemPointerFromDiskOffset
if ( Mem stripe HIT) {
//将该mem stripe锁定，不允许被swapout到Disk
//即使在mem stripe都被占用的情况下
storeCossMemBufLock
If (storeCossRelocateRequired) {
//当满足relocation的要求时，object很久没有被访问过了
storeCossAllocate
//object刚被访问过，就存在后面不远的stripe处，不必马上relocation
storeCossMemOnlyAllocate
//这个函数内部，当mem stripe占用满了时，就会提醒
// storeCossCreateMemOnlyBuf: no free membufs.
//You may need to increase the value of membufs
If (mem stripe占满了) {
//内部会将已经写满的stripe写到Disk上，同relocation的情况
storeCossAllocate
………………
………………..
3. 案例分析
3.1. 案例1
案例描述：
对Squid服务器做了加压的尝试，使用COSS，但log里面出现了
10:26:27| storeCossCreateMemOnlyBuf: no free membufs.
You may need to increase the value of membufs on the /cache/coss13 cache_dir
然后导致cache hit service time达到了秒级的响应时间，正常的情况下一般在6ms左右
从上面的分析可以看到，当提醒“storeCossCreateMemOnlyBuf: no free membufs.
You may need to increase the value of membufs”时，是由于mem stripe被占满时才提醒的。正常情况下，当mem stripe的M个stripe都占满时，squid会将部分mem stripe swapout到COSS文件上。但当storeCossMemBufLock锁定了某个mem stripe的话，则不会执行swapout。而当某个mem
stripe中的object正在被访问（Object Cache HIT）时，则mem stripe被Lock，服务完成后，即会Unlock。
这个信息是在storeCossOpen（Cache HIT）的内部执行过程中被输出的，因此分析这个函数是关键。
因此，本例的结论应该是：
提示信息是由于正在被访问的object在不久前被访问过（这里的不久是指，当overwrite-percent缺省为50%时，是指在整个COSS文件遍历一次的50%的时间内。如果不理解的话，看一下代码，minimum_stripe_distance的计算方法），因此COSS的relocation机制storeCossRelocateRequired认为该Object不应relocation，所以希望用mem stripe来存放。但找不到空闲的mem stripe来存放这个object，所以只能relocation（后果是relocation使得这个被访问的object应当前游标下的stripe，下次再访问时这个object时，这个stripe又足够新，以使得又不满足relocation条件，从而又希望用mem
stripe来存放——形成恶性循环）。
之所以找不到空闲的mem stripe，极有可能是由于Squid负载过重，导致每一个Object服务时间长（Mem Stripe中的object的Lock周期也长），从而由于并发Lock的数目也增大，直接导致mem stripe被占光。
从之前没有出现这种现象来推测，应该通过降低响应时间来解决这个问题。当然，从之前的技术分析可以看到，修改overwrite-percent，加大membufs数目都可以解决这个问题。但根本的原因仍然是Lock与Unlock的周期过程，即热门的Object服务时间过长。
4. 关于使用COSS的建议
从我们对COSS的技术分析可以看到：
.COSS使用stripe与block来管理文件，不能充分利用硬盘空间
.COSS由于使用relocation，导致增加写操作
.COSS的rebuild过程需要分析整个COSS文件，因此费的时间非常长，而且在rebuild过程中不能服务
.由于fileno只有24位，因此，支持的COSS文件大小有上限
.当COSS文件有文件删除操作（Cache Purge）时，导致COSS内部大量空洞，每个stripe的object数目变少，读写效率下降
.COSS无法有效支持基于目录的刷新扩展，以及更深层的内容管理
.COSS支持的Object大小有一个上限值
COSS的优势：
.较AUFS、UFS来说，避免了大量（每个Object访问一次）open/close系统调用
.更加可能使用相对连续的空间来存放文件（操作系统优先使用连接空间的分配，在COSS创建时），可能能有效利用了OS的ReadAhead预读作用（预读的stripe中，可能包括后面将要访问的object）
上面的分析可能不够全面，但我们仍可以看到，对于普通硬盘来说，使用COSS可能会对小文件的服务性能有帮助（主要是通过减少open/close，代替的是使用大量的lseek），但当有以下情况下，COSS可能不是最佳选择：
.使用SSD硬盘的设备。SSD读能力非常强，但写能力较差，COSS会增加写操作，反而较AUFS差
.有频繁的文件更新或删除（Purge）操作
.当访问的热点文件比较集中，但大于mem stripe可以存放的大小时。可能引起mem stripes满后，频繁的relocation，而从陷入案例一类似的恶性循环。
.对于Squid启动速度有较高要求的
最后，是否使用多Squid架构，以及使用什么样的Filesystem，本质上，要依据业务来定。从计算机体系架构上来看，整个系统简单的看，主要由四个资源组成：计算资源CPU，存储资源（内存与外存储），IO（这里特指网卡，因为外存也是通过IO），以及连接他们的总线。
要对Squid做优化，首先要看看对于特点的业务来说，这四个资源什么是瓶颈，是CPU还是IO，充分利用多CPU可以使Squid充分利用多CPU的计算资源，减少“串行”操作的等待时间。但是，当多个Squid使用多个coss文件时，本身也会增加一些开销，其中一项就是增加IO的竞争开销。如果参数设置不合理，IO竞争的开销会使IO的等待时间更多（使用iostat –x的await、avgqu-sz可以分析）
&&&&推荐文章:
【上篇】【下篇】怎么我电脑C盘有一个文件叫
(CFLog)删了,过一下子又有了,是不是病毒?_百度知道
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。
怎么我电脑C盘有一个文件叫
(CFLog)删了,过一下子又有了,是不是病毒?
我有更好的答案
cf=cossfire你肯定玩穿越火线!cflog就是这个的临时文件
采纳率：27%
日志文件会产生新的，所以删除后还是会有。如果楼主不放心的话，可以通过瑞星官网下方的病毒文件上报这应该是楼主玩的游戏的日志文件，不是病毒
看后缀名,如果不是 exe ,bat ,com 以及dll ,那么就不是病毒,估计是某个软件的运行记录
某种日志文件，你用了ColdFusion？给你查了一下，好像是这个软件的日志文件，应该不要紧
穿越火线! 游戏的记录文件。
其他2条回答
为您推荐：
其他类似问题
cflog的相关知识
等待您来回答当前位置：
& 剑灵文件夹里的COSS文件夹删掉更新后这个COSS的文件夹会不会还会在
剑灵文件夹里的COSS文件夹删掉更新后这个COSS的文件夹会不会还会在匿名 19:45}