mfs write data

数据对错误信息处理。对于严重错误直接跳过。
其他的错误，进行多次尝试，

一个inode的所有节点是按照什么顺序来发送的。
发送总是从datachainhead 开始，可以知道，发送完一个，
节点就应该会清除。
有两种工作者，一种是处理开始的对象，另外一种是处理失败后，延迟的对象。

写数据会发送两次请求，第一次是发送给元数据管理。
并不会发送具体的数据。
返回的数据里面主要有ip 和port。


一次写一个inode 节点的数据。多个块。
循环执行，从inode 的节点头开始。

这样看来数据发送是单独的，并不会决策数据写入。

这样不同次数的写入也是被允许存在的。

数据写入，应该是被共同允许的。


    pthread_mutex_lock(&glock);
//    syslog(LOG_NOTICE,"write_data: inode:%"PRIu32" offset:%"PRIu64" size:%"PRIu32,id->inode,offset,size);
//    id = write_get_inodedata(inode);
    status = id->status;
    if (status==0) {
        if (offset+size>id->maxfleng) {    // move fleng
            id->maxfleng = offset+size;
        }
        id->writewaiting++;
        while (id->flushwaiting>0) {
            pthread_cond_wait(&(id->writecond),&glock);
        }
        id->writewaiting--;
    }
    pthread_mutex_unlock(&glock);

这里决定了数据写入的顺序。
writewaiting 写入数据都需要在此等待。

在
        id->writewaiting++;
        while (id->flushwaiting>0) {
            pthread_cond_wait(&(id->writecond),&glock);
        }
        id->writewaiting--;

怎样测试前一次不完成后一次是不会输出的。


    id->flushwaiting--;
    if (id->flushwaiting==0 && id->writewaiting>0) {
        pthread_cond_broadcast(&(id->writecond));
    }

这种管理可能个更多接近于文件系统的管理，管理的单位是块。

也就是说如果flush 没有完全处理掉，就不能够写。
意思是进入了一个文件的flush之后是不允许在被写入的。
需要等待flush完毕。
或者write_data_end  write_data_flush_inode 其中之一。
1 write_get_inodedata - Reference in Writedata.c at line 198
2 write_free_inodedata - Reference in Writedata.c at line 214
3 write_data - Reference in Writedata.c at line 932
4 write_data_flush - Reference in Writedata.c at line 995
5 write_data_flush_inode - Reference in Writedata.c at line 1039
6 write_data_end - Reference in Writedata.c at line 1062


查看mfs log 没有必然的关系。

他们好像是自然而然出现的。没有串联的情况。

两个操作是可以并行的。但好像本身是有顺序的。不然应该是在wakeup 之前。
下一轮的其他操做就会进行了额。

lookup (1,aa)
lookup inode 6029 - file size: 2
open (6029)
open (6029) ok -> keep cache: 0
flush (6029)
write to inode 6029 16 bytes at position 2
test,sleep....................
lookup (1,aa)
lookup inode 6029 - file size: 18
test,wake up........................
16 bytes have been written to inode 6029
flush (6029)
flush: wait ...
getattr (6029)
open (6029)
open (6029) ok -> keep cache: 1
flush (6029)
flush: wait ...
flush: woken up
flush: woken up
release (6029)
write to inode 6029 16 bytes at position 18
test,sleep....................
test,wake up........................
16 bytes have been written to inode 6029
flush (6029)
flush: wait ...
flush: woken up
release (6029)
getattr (1)
lookup (1,aa)
open (6029)
open (6029) ok -> keep cache: 0
read from inode 6029 up to 4096 bytes from position 0
34 bytes have been read from inode 6029
getattr (6029)
flush (6029)
release (6029)

有没有可能它不是多线程处理的？？

也有可能。下次再看。

处理过程中使用的仍然是多线程。
那么是谁负责线程间的阻塞调度。


两次交互操作和一次之间的差别仅仅是
第一次中间插入了lookup 。但是它是返回了的。

按照一般规律，
应该是一个请求到达，发现文件被访问，然后等待条件成熟返回。

也有另外一种方式：请求到达，发现文件被访问，那么把这种情况返回。
这个上级程序能够处理吗？
它能够知道文件正在被写入，所以将这个命令押后了。
可以做更加确切的调查，
将写另外一个文件的job也放进来。
同一个文件的两次写同时开始。
后一个文件等待1秒。
如果后一个文件先于第一个文件的第二次写入。
那么说明确实有这种处理。


没有出现预期的情况，也要等待第一个先完成后才能进行下面的。
但接下来的是共同进行。

修改为 三个文件 aa bb  cc  其中aa 被写两次。
结果发现aa bb cc 这三个文件可以被同步写入。
看来这才是最正常的情况。
这说明了同一个文件的写入时不会同时发生的。
但是open 之间是可以的。
mfs 可以允许两个不同的写入依次完成。
vfs 不会同时发出对于一个文件的写入。

等等，可是连这个文件也不能被open。