分布式文件系统的设计 1

想设计写一套自己的分布式文件系统，以试验对公司目前文件系统的一些想法。

文件系统的目标，主要有几下几点：

1. 支持Posix语义，但是提供不支持的API,这样，可能工作得更好。

2. 无Master中心。 预计一个单节点文件系统的规模在 1024台左右，每台磁盘数目 0－32。

每个磁盘大小1T-2T.也就是一个单节点，最多64PB数据.考虑冗余，可能只有32T的不同数据.

支持多节点。考虑是一个节点，存在一个机房。最多32个节点。 也就是整个文件系统，最多

32节点。（这方面，没太多经验，对于有大规模计算任务的系统，每个节点，数据并不太多。

一个机器32T,数据太多。 计算型节点？ 存储型节点？32*64PB 的数据，能组成全局文件系

统么？64位的机器上， 2^64B > 2^11 * 2^10 * 2^10 * 2^10 * 2^10 * 2^10= 2^61B。 

3. 支持小文件。 

    chunk 4M -16M . 如果4M 一个单位，2^39 个chunk需要维护。 平均每台机器需要维护

2^29个chunk左右。，每个chunk所需要的维护信息按1K算的话，单个系统需要有512G内存.不行。

考虑系统内存只有48G的情况。 每个节点，只能维护？。。。。待续。如果只有48G 的话。

如果固定一个文件的chunks数目的话， 让每个 chunk的大小可变化。这里的问题是？一个chunk

太大，对文件系统的读写，会出现问题，文件系统要实现类似文件区间锁类似的机制，使得并发能更高。

整个这样设计的目的是：不论小文件，大文件，都有可能有高的并发。（这里，跟chunk大小有关系，

问题是：chunk大小合适, ）并发有两种： 一种是多用户的并发，一种是单用户的并发。多用户的并发指的

是多个用户访问一个文件的并发？ 但用户的并发指的是单个用户访问整个文件的并发。希望淡个用户访问

一个文件的并发，在一个文件的chunks数目左右，多个用户访问一个文件的并发数，3M，(读，写语义需要确定）

一个文件，希望做到的，是有chunks * (number of pieces in one chunk)，这个数，在100左右。我的理解， 这是个真实并发，当然不是并发客户服务数。 这样一个系统， 我们可能是无法做 cache的，甚至，我们会强制禁止cache. 一个硬盘1T数据，内存 很难超过 1T, 适当的方式，合并读请求，必要么？（每块内存，使用完，并不立即回收，恰当的时候，回收。（当文件被写的时候），回收也仅仅是用新的数据，覆盖原来的数据----想得到美，！ 怎么设计？)

    总结：支持小文件，chunk大小不唯一，小文件，大文件，的chunks? 

4. 现在想起来，google的gfs,确实有点特殊。。。. 

   暂时把文件系统的设计，分为下面几层：

   1> 网络层

       1> 拓扑， 通信

   

   2> 名称空间

   

   3> 读写语义

   

   4> 标准语义