baidu / bfs Goto Github PK

当前client每次打开文件时都需要向nameserver发送GetFileLocation请求，是否有必要做一个缓存，或者一次GetFileLocation时，将邻近文件的信息也发送回来？

我看到levelDB-split中分裂tablet时，对原sst文件做了硬链接操作，然后去构造manifest。dfs有没有必要支持硬链接？

d96b06d

有点乱。。需要捋一捋。。。

commit 1e0d8ad让我想起了一个问题，当前mutex.h中的Mutex类在初始化pthread_mutex_t变量时，没有指定pthread_mutexattr_t属性，这将导致该互斥量的属性为PTHREAD_MUTEX_DEFAULT。而在linux下，这种属性的互斥量在 没有解锁时又重新加锁 下的行为是未定义的。是否有必要将互斥量改为非递归的？感觉这样会安全些。

当前chunkserver接到pullblock的任务后，就丢到线程池里，在系统整体负载较高时，线程池消化任务速度很慢，导致后来的hi级别的recover任务排队很久。
由于系统负载是波动的，这里不能简单的由nameserver用并发控制，同样是1G的文件，在系统负载低的时候chunkserver可以在3秒钟内完成，但系统负载高的时候可能需要3分钟。

• dir/file access control
• user management
• 目录&文件的访问权限控制
• 用户管理

当前存在的问题

1. 按数据量算负载，所有的机器数据量完全平均，导致大磁盘机器利用不足
2. 对pending的限制只有个上届，会导致一些chunkserver的pending在上届徘徊，另一些有很闲

改下选取chunkserver的算法

1. consistency problem between ChunserverManager and BlockMapping
2. ChunkServerManager和BlockMapping的一致性
   之前有问题（在AddBlock是更新了后者，没更新前者，前者是在BlockReport时更新的，这就导致在report这个block前，chunkserver挂掉，那这个block不会DeadCheck被恢复，更严重的是Blockmapping却认为这个block的replica是存在的，等另一个chunkserver挂掉时，将它拿去做PullBlock的源地址了。

1. close和sync长期不返回，初步判断是重试时间间隔太长，5次，每次一分钟
2. 副本恢复存在问题

由于后续开发，原gc逻辑有些冗余设计。简化思路：如果在mapping里找不到cs上报的block，直接在response里要求cs删掉该block。

从日志分析看，16:59:03时，block被ChunkServerImpl::RemoveObsoleteBlocks给删了，具体原因我还没找到：
chunkserver日志：
05/27 16:59:02.873031 30287 [src/chunkserver/chunkserver_impl.cc:685] Writeblock send [bid:10015, seq:427] to next yq01-tera64.yq01.baidu.com:8825
05/27 16:59:02.873835 30253 [src/chunkserver/chunkserver_impl.cc:729] Writeblock send [bid:10015, seq:427] to next done
05/27 16:59:02.873874 30253 [src/chunkserver/chunkserver_impl.cc:752] WriteBlock done [bid:10015, seq:427, offset:28667909, len:49603]
05/27 16:59:02.930921 30285 [src/chunkserver/chunkserver_impl.cc:653] [WriteBlock] [bid:10015, seq:428, offset:28717512, len:0] 1432717142922856
05/27 16:59:02.930941 30285 [src/chunkserver/chunkserver_impl.cc:685] Writeblock send [bid:10015, seq:428] to next yq01-tera64.yq01.baidu.com:8825
05/27 16:59:03.606987 30256 [src/chunkserver/chunkserver_impl.cc:729] Writeblock send [bid:10015, seq:428] to next done
05/27 16:59:03.615835 30286 [src/chunkserver/chunkserver_impl.cc:487] Remove meta info done: 10015
05/27 16:59:03.621214 30286 [src/chunkserver/chunkserver_impl.cc:104] Block 10015 deleted
05/27 16:59:03.730070 30256 [src/chunkserver/chunkserver_impl.cc:203] Write block 10015 offset[28717512] block_size[0] not in sliding window
05/27 16:59:03.735733 30285 [src/chunkserver/chunkserver_impl.cc:653] [WriteBlock] [bid:10015, seq:428, offset:28717512, len:0] 1432717142922856

No testing yet, but it feels like a bottle neck here...
每次都需要重新计算负载，排序，然后再选择，感觉略慢……

maybe a third strategy, chains and fan-out. Write to a primary and that server will fan-out from there.
除了扇出写，链式写之外，有没有必要再添加一个这两种混合的写模式？SDK先写主副本，然后主副本进行扇出写。

d96b06d

当前nameserver中元数据是存储在本地磁盘上的，是否有必要将其以其它方式进行存储，比如存到ins中去，后面便可以同时起多个nameserver?

好好编辑下Readme，然后把repo挪到github.com/baidu下

当前还暂时无法通过block version来删除扇出写中的慢节点。
可能扇出写本身还有一些问题，先在这里记下。

chunkserver在nameserver判定宕机后重启，当前没有问题
chunkserver瞬间重启nameserver不会更新quota等信息

当前PullNewBlocks中，所有的block是逐次进行Recover的，是否有必要改为不同block同时进行？

./bfs_client put filex /diry，若diry存在，且为一个目录，那么就悲剧了。。。目录没了，下面的文件也没了。。。另外，O_TRUNC时，应该把之前的block删掉。

对于一个已打开的文件，是否允许多线程同时读？

如果3个chunkserver 其中一个写成功并close了block，一个重启了，另一个还处于writing状态。
这种情况下block是完整可用的，但重启的chunkserver的block无论是有没有dump，都可能被丢弃。
导致副本数不足，开始修复，修复的时候如果选择的source是处于writing状态的，会一直修复不成功。

这里本质问题是block还有处在writing状态的副本，本应该进入incomplete，不能进行副本恢复。

当前新block选择chunkserver的逻辑是“按数据量加权的随机化”，即：选择哪个chunkserver是随机的，每个chunkserver都可能被选中，但数据量越小的chunkserver被选中的概率越大。
由于并没有考虑chunkserver的负载，当数据量小的chunkserver磁盘io被打满后，会拖慢整个集群。

chunkserer会将正在pull的block报nameserver，pull失败了，但没删除

如果每次都是顺序读的话，sequential_ratio_会一直增加，然后sdk在实际rpc时选取FLAGS_sdk_file_reada_len与read_len * sequential_ratio_中较小的那个。
然而，sequential_ratio_很大之后，read_len * sequential_ratio_会变为负数。。。再取最小值，后面就会么也读不出来了

比如ls fuse_mount_point/stat_table/tablet00000001/这个操作，会将整个链路中的stat_table, tablet00000001目录都stat一遍，还会将tablet00000001下非目录的文件做一个GetFileLocation，估计是做缓存什么的了，比如本地文件系统里会缓存一些dentry和inode，fuse估计也是走的这个逻辑
然而这大大的增加了NameServer的压力，而且有些东西我们是不需要的

1. Logging.h按时间&大小切log
   Logging.h switch file when the file reach a size limit
2. 多盘负载均衡
   Load balance between disks
3. 异构机器调度
   Load balance between different server type(disk number, etc)
4. 机架感知
   rack recognize
5. master热备
   Master HA
6. chunkserver停机dump数据
   chunk server should close opened files before shutdown
7. sdk端sync支持超时
   sdk support sync timeout
8. 副本恢复与gc逻辑使用后台扫描触发
   background gc and replica recover strategy
9. SDK里File结构的生命周期管理
   Managing file cycle for files in sdk
10. 统一SDK里两个CloseFile逻辑
    There are tow CloseFile in SDK.
11. webservice实现剥离出nameserver_impl
    Separate web service from Nameserver_impl
12. 错误码，人性化报错
    Make error code readable
13. 读写文件优先选择Client本地副本
    Read/write local copy first

当前的逻辑：
如果发现版本号不对的replica，立即清理掉，然后发起副本修复。
这样如果3个chunkserver close到的版本不一致，只会保留最高版本的，其他两个会被删除，会有一段时间存在单副本，这个时间版本最高的chunkserver宕机，会导致丢文件。

正确的逻辑：
先将最高版本修复到3副本，然后再删除低版本。如果在修复过程中最高版本的chunkserver宕机副本丢失，那nameserver将block版本修正到一个较低版本，然后重新进行副本修复。这样即使丢数据也是丢一些没sync过的版本，而不是丢文件。
如果过段时间，新版本的chunkserver又起来了，那nameserver重复之前的逻辑，重新修复副本，直到讲最高版本修复到3副本，才删除低版本的block。

实现确实略复杂，当然还有另外一个思路，保留最低版本而不是保留最高版本，不过实现复杂度不变。

当前冗余副本在UpdateBlockInfo中判断，通过返回false清理，导致的问题：

1. 一个刚写完的block会在BlockReport和BlockReceived中同时上报NameServer，如果前者先到并被清理，这时另一台拥有这个block的机器宕机，那后者会被UpdateBlockInfo插入block的replica。这时chunkserver实际上已没有了这个副本。
2. 一个Pull成功的block，也会出现上述情况，BlockReport和PullBlockReport同时上报，因为原来有这个block的机器重启，BlockReport后会清理这个block，但这时另一台chunkserver宕机，副本数又不够了，NameServer会接受这个PullBlockReport。
   暂时没想到好方法解决上面的问题，所以暂时关闭了冗余副本的清理

使用方式
./bfs_mount mount_point [-c nameserver_address] [-p path_on_bfs]

当前代码中有的地方对GetStub的返回值进行了判断，有些地方没有。
rpc/rpc_client.h中的GetStub实现没有返回false的情况。
那么，GetStub究竟有没有可能返回false?

在两个DeadCheck之间插入GetChunkServerChains时可能返回dead的cs

A chunkserver挂了，block被分配到B chunkserver上去recover，但这时B也挂了
当前没有机制迅速触发这个这个block另选机器recover，只能等recover超时，如果这个block是个单副本的block，会非常危险。

对于block副本数的维持，当前作法是　副本数小于要求 & 不处于第一轮block report　时，会发送pull block请求。
当初这样做的考虑是，如果不等待一段时间，那么由于chunkserver启动的先后顺序不同，有可能会造成不必要的副本复制。
但是，分批进行block report之后，这样也有问题了。因为每个chunkserver每次只汇报部分block，当chunkserver连接到新的master时，还是很可能会导致一些不必要的复制操作。
目前想到了三种方法：

1. chunkserver连接到nameserver时，先作一轮完整的汇报，后续汇报分批
2. nameserver等所有新连接过来的chunkserver都至少进行过一轮完整的汇报后，再考虑对副本数不足的块进行复制
3. 直接让nameserver启动后等待一段时间再允许复制

docs/README.md中提到chunkserver支持全异步写，请问一下这是什么意思？是DiskWrite()时用POSIX AIO吗？还是说在RPC时就把数据流和指令流分开？
还有增量report，这个之前提到过一次，是说对所有block进行分批report呢还是说只在block有变动时报告增量？

区别这里有描述
主要优势

1. 支持高效的目录移动，只需要修改目录入口即可
2. 后续添加基于树形目录结构的权限控制更方便

副本恢复有必要做吗？好像这不是一件太容易的事……

We have load balance when create a new block. Do we need load balance afterwards? For example, a new server join the cluster, it will take a long time for it to catch up with others.
当前实现中，只考虑了在写入时对chunkserver做负载均衡，是否有必要在后续过程中继续进行负载均衡的操作？好像tera中也会有负载均衡的功能，如果做的话，两者会不会冲突？

LocalWriteBlock里，会先调用Block::Write()将数据包放入sliding window，然后调用IsComplete判断是不是所有数据包已经都从sliding window中取出，如果是，将会调用CloseBlock将文件描述符关闭，同步元信息。而实际上，IsComplete并不一定会在对某一个数据包执行LocalWriteBlock时成立。

sdk写一个新文件，nameserver已经分配好cs，但是sdk还没有写cs，其中一个cs就挂了。nameserver close incomplete block，但是cs并没有创建block对应的实际文件。三台机器如果都挂掉的话，文件lost

目前chunkserver中唯一关闭文件描述符的地方是Block的析构函数。而当前内核对于每个用户进程的最大打开文件数是有限制的。即使修改了限制，也会造成系统资源的浪费。是否有必要去关闭一些文件呢？

我看到TODO中有一项是　扇出写支持　这个是什么意思？
另外，那天的core怎么样了？

每次nameserver重启时，都会把所有的block标记为pending_change=false
但这些block中可能有些正在被写入，写入完成后FinishBlock调用MarkBlockStable会导致assert失败

当前一旦认为某个chunkserver挂掉后，便会在下一次接收到block report时考虑副本复制。是不是有必要将复制动作稍微推迟一些，毕竟有可能过了一分多钟机器又起来了

在检测到cs挂掉时，只将CheckList中的block重新加入到了recover的队列中，并没有取消超时触发的CheckRecover task
这样，当其它cs pull block正在进行过程中，若此task被执行，则会错误的在CheckRecover中将block的状态改为kNotInRecover