ChunkServerImpl::RemoveObsoleteBlocks会删除正在写的文件 about bfs

[bluebore]

问题应该在sdk，在还有BackgroundWrite运行时，就close成功了，导致文件被删除后还在写。

[yvxiang]

我下午复现一下这个问题。

[yvxiang]

我初步的认为情况可能是这样的：
当前每个block接收Buffer的sliding window大小为100。如果文件在写的时候被删除，那么会将该block的信息在chunkserver的block_map中删除，同时减少这个block的引用记数。在写完一个packet之后，也会减少这个block的引用，这时很有可能引用记数达到０(如果当前没有读者的话），从而引起block结构的析构，继而销毁sliding window。而写者对此并不感知，继续写。当下一个packet到达chunkserver时，WriteNextBlockCallback中FindBlock处设置的为create_if_missing = true，则会新建一个这个block的信息。但是放到sliding window中时还是使用原来的seq。这样，重复若干次之后，seq超过100，从而引起Block::Write中的assert(0)
在我的机器上这个场景是可以复现的，只要要写的文件大小能够使seq超过100，并且写文件过程中，文件被删除即可。

[yvxiang]

解决方案很简单，只要在WritNextCallBack中FindBlock前判断一下seq是否为0即可。
但问题是，为什么文件在写的时候被删除呢？还是说tera中的确有这种场景？
至于还在BackgroudWrite写时，文件就close成功我还没有复现出来。

[bluebore]

这里有两种场景

1. 你模拟出来的那种，文件在写的时候，就被删除了，会出问题，这个是我们设计没考虑到的。
2. tera中每个文件都是由单一机器中的单一线程操作的，在写的过程中不会被删除，我遇到的场景是写完了，close成功后，删除，但还有后台写操作在。这应该是一个bug。

[yvxiang]

从发起文件删除命令，到block被真正在chunkserver上删除，至少要经过一次block report的时间，也就是60s。chunkserver上的block是在16:59被删除的，16:58附近nameserver上的LOG有吗？以及SDK部分的LOG

[yvxiang]

seq为428的packet长度为0，说明之前的所有包都已经被写完了，调用close时发送了一个空的包。在这个时间点附近应该可以找到bfs_wrapper中close file的LOG

[yvxiang]

seq为427的packet长度为49603，不是256 * 1024的整数倍，而且后面seq为428的packet长度为0，说明文件是在sync之后紧接着被close的。
先sync再close再删除，我测试了大概50GB的数据，没有复现出log中的情况……所以我感觉只能进一步分析更完整的日志来排查原因了。

[bluebore]

这个周末我出去了，今天我继续跟进下这个问题。
现在怀疑是用户close返回之前，就将文件删除了。

[bluebore]

上层应用在Close返回之前，就删除了文件，导致还未完成的写操作失败。当前解决方法是针对写操作中的失败，设置后台错误标志，在用户进行下次close或者sync时返回失败。
6956a5e