2011-03-21 随机读写

随机写和随机读是否能够同时发生。
在打开文件时如果选择的是读写模式。

在open 和release 之间， read 和write 是没有必然关系的。

11:36:41[INFO][19363 ][88820592][       proxyfs_open],fi 163020048 file: /aa ,Size:13
11:36:41[INFO][19382 ][122391408][       proxyfs_read],path:/aa fi 163020048  offset:0 size:13 
11:36:41[INFO][19406 ][122391408][          LoadCache],cache[8d0e689772e05cb262a207c76fbd97cb]  is on disk !
11:36:41[INFO][19459 ][159894384][      proxyfs_write],start fi->fh 163020048 /aa 4 10
11:36:42[INFO][19540 ][159894384][      proxyfs_write],end /aa 4 10 file->Size:13
11:36:42[INFO][19572 ][97213296][    proxyfs_release],start file: /aa,Size:14
11:36:42[INFO][20033 ][97213296][    proxyfs_release],before send_data !
11:36:42[INFO][20183 ][97213296][    proxyfs_release],end send_data !
11:36:42[INFO][20187 ][97213296][    proxyfs_release],end file: md5 7ce2e1f0bcc3dd5bcfafd19e254d74bc ,Size:14

没有第二次的读取，但是内容是正确的。
bbb
defgh
4
bbb
efghijk

系统存在缓存。系统对这种写后立即读的操作做了优化。去掉第一次写，发现数据出错了。读取的内容是上一次的。
3
bbb
efghijk
所以优化的是读写读。并不是写读


我们的读写对于这样的操作并没有做设计。
写后立即读这种情况。
我们把数据放置在了临时文件中，这个时候如果读取应该是读临时文件。
如果文件被修改了。并且没有更新。


从open 到release 使用一个file 对象。
open操作能被多次打开吗？应该是支持的。
那么在open处把打开的对象放入静态表，这样本身就

truncate 后并不一定会接着写入。
那么文件内容应该是单独的，

读写需要进行权限验证，
从打开到关闭，这个期间有其他人想要打开，需要知道它想干嘛？


文件正在被写入时，我们应该不允许以写入的方式打开。
如果有文件正在被写入，但是超过时间没有释放，那么如何。
主动释放吗，把内容先push。
这种情况应该在程序编写时才会出现而且是被杜绝的。

手动写入时 是否这种情况。
手动时间差很大。难以模拟共同写入。
采用脚本，模拟， write操作 进行休眠处理。
发现写入内容只有最后一次的起作用。
但文件size 是正确的。先写入16位。
这个时候再写入直接从第17为开始。
说明系统内部知道文件的长度，open 的时候给出的长度都是1；
我们本身操作的不是同一个对象。
都是把文件先拷贝过来。
正确的顺序是，
是否允许两个这样类型的写操作。
如果一个在写，那么应该是等到他写完了再写另外一个。

我们这里和正常的本地系统和网络系统都不同，
条件约束我们只能是传递整个文件。
这样只有等待一次操作完成后，我们才能进行这种

整个文件写入这里在本地本身就是应该可以控制的。
让一个程序在另外一个写完后再写。这是一个原则。
在本地就可以控制好。

至于大文件写入问题。可以通过将数据写入接口。

服务器做牵线处理，
根据文件大小分类。

大的文件，服务器提示客户端建立和onest 节点的接口。
数据不通过服务器。这个不好实现。
数据流通是两个ip 之间的是。
提供一个windows 的接口比较可靠。


写入时，根据模式判断是否有本地文件正在写入，
对一个文件写入进行文件写入锁。
一个文件正在写入时，是等待打开，还是不允许打开。
这个应该根据普遍的原则。


做到一个正在被操作的文件对象在系统中只有一个。
那么就可以根据这个对象来判断这个文件的使用情况。
release 并不需要把文件 彻底删除，
把文件的n_links 设计上。

只有当links 是0 的时候对它进行释放。


status = fs_opencheck(ino,ctx->uid,ctx->gid,oflags,attr);

mfs 中没有通过本地来判断文件的操作是否被允许。
而是发送命令道服务器。
这样保证了文件全局的使用。
猜测：如果文件之前已经发送了写的请求。那么这次发送过去的请求时不会被允许的。
本地客户端，和其他的客户端都被统一管理了。
它做的操作是汇报出错，返回。
    if (status!=0) {
        fuse_reply_err(req, status);
        return ;
    }
需要检查服务器端来进行该项检查。