这几天，我们扩展了dfs的一些功能，特别是增加了批量上传的功能和更改了文件的上传路径功能，这些功能使我们的dfs更容易的管理，更节省资源。

先说说更改文件路径这个功能。这个功能是我一个同事更改完成的，据了解，他在storage_service.c这个文件中找到storage_gen_filename这个函数，并在里面组织文件存放路径时在路径的前面加上了“YYYYMM”的代码，这个地方需要注意，并不是单单只在这个地方更改就ok了，因为dfs在第一次启动storage服务时会建立起目录，在建立目录的时候也需要做相应的更改。这些更改完成后还要记得做一件事情，这件事情也是后来我们正式环境中发生的，dfs存放目录是按照一个文件夹文件数达到上限后再存储在下一个文件夹，这样的话就会出现一个“计数器”问题。当月份更改的时候，按照我们更改的代码，图片将会存储到下一个“YYYYMM”文件夹内，这个时候，因为dfs文件计数器的关系，计数器并未清0，所以得到的文件路径将是YYYYMM\XX\XX，而不是YYYYMM\00\00，因为月开始，文件路径肯定是从最小的开始。这个时候我们就需要在storage_gen_filename这个函数中再增加几行代码：

time_t times;
time(&times);
struct tm *timep = gmtime(&times);
if(1 == timep->tm_mday && 0 == storage_path_month_change_state)
{g_dist_path_index_high = 0;g_dist_path_index_low = 0;g_dist_write_file_count = 0;storage_write_to_stat_file();storage_path_month_change_state++;
}
if(1 != timep->tm_mday )
{storage_path_month_change_state = 0;
}

这段代码其实效率一般，因为这段代码其实应该是一个月才执行一次，但是目前写在storage_gen_filename这个函数中，每次上传文件的时候都会执行，至少需要执行判断，所以大家如果有兴趣的话可以把这段代码写成一个事件，每一个月开始时执行一次。

还增加了一个批量上传文件功能。此功能实现起来比较复杂，牵连到dfs通讯协议，dfs系统thread_stack_size大小等等的关系。但是还好有高人协助，终于是完成了。

先说协议，dfs其实使用byte值做通讯协议的，详细请查看tracker_proto.h文件中定义的协议，比如规定了tracker检查storage健康状况的协议为83，等等。那么下面就是传输内容，首先dfs客户端会传输一个proto包，这个包长度为10个byte，其中8位是一个body的长度，body其实就是客户端向服务器端正式发送的处理内容，接下来的1byte就是刚刚说的协议值，告诉dfs服务器下面我要做什么；最后1byte是error错误号，这个error其实在客户端向服务器端发送的时候没有什么用处，它主要是用来做服务器向客户端发送服务器端错误的。

下面传输内容，内容有几块组成，第一块是内容长度，比如文件扩展名长度，metedata长度和file的bytes长度，这些长度是一个long值，这些long值传输是全部使用byte数组表示，每个byte数组的长度为8，所以一般情况下这些固定长度的内容先传输，服务器端可以接收并解析以后可以根据这些长度去网络流中接受相应的数据。这样就可以得到下面流中不同的流位置表示的含义；下面传输真正的内容，先传输扩展名，在传输metedata，最后是文件bytes数组。这些可以合并成一个bytes传输，因为上面已经解析出各个不同数据的bytes长度，所以可以从流中截取。

批量上传也是这个道理，但是新增加了一个dfs的协议值，我使用的127，当然了，这个可以自己定义值，只要是dfs中没有使用过的就可以。但是必须保证你的客户端和服务器端定义的协议相同。否则无法解析。那么还有一个需要注意的地方，就是thread_stack_size这个值，这个值是在config文件中配置的，表示的意思是dfs单线程最大的内存使用数，当批量上传时，因为你处理的内容多了，所以很容易就会内存溢出，所以在增加了批量上传以后最好把这个值调整到2mb， 当然为了优化性能，我已经把dfs服务器解析文件的方式使用单文件处理的方式处理掉了。所以看服务器端或者客户端代码时会看见一个for循环处理单个文件的byte数组。