peon

不好意思，这个问题我有点回答不了，因为对于文件系统不够精熟，大家姑且看之

第一个其实可以认为是一个假的操作，UNIX里面有这个机制，不会占用实际空间，假如拷贝到另外一个文件，拷贝出来的文件就有实际的内容和长度了，好像会填写0，因为hole的部分读取出来是0。

直接分配簇的话，肯定会有inode的操作和meta的操作，这个会占用几个磁盘操作，但是假如是大量IO的话，我就认为是会擦除原有的区块内容了。我认为从性能的角度看，最好不要这样做，我们的确也没有这样做。但是从安全性的角度，通用的文件系统应该擦除原有的内容。

Frank

加你MSN了。

请教一下，是否尝试过“ 基于集群的主机+iscsi的方式。IP的成本和性能都可以兼顾。

冬瓜头

引用:

原帖由 peon 于 2008-5-10 19:49 发表
不好意思，这个问题我有点回答不了，因为对于文件系统不够精熟，大家姑且看之

第一个其实可以认为是一个假的操作，UNIX里面有这个机制，不会占用实际空间，假如拷贝到另外一个文件，拷贝出来的文件就有实际的内容 ...

谢谢了，peon兄果然厉害！

冬瓜头

还有个细节问题，如果是第二种方式，分配了inode等，不擦除原来的扇区内容，此时我如果要读取这个文件，那么读出来的是不是僵尸扇区，如何避免这种情况，是不是文件元数据保存一份文件自身的map信息来标记哪个offset没分配，哪个分配了？谢谢
或者只分配到indirect block这一层，最后一层指针全是hole，用的时候现用现分配？

[ 本帖最后由 冬瓜头 于 2008-5-10 20:00 编辑 ]

Frank

云计算相信是未来一个趋势，几个出名大厂商都特别关注这个。

Frank

有那位做个普通网卡，使用IP捆绑后普通网卡，TOE卡，ISCSI卡 这4种的测试对比呢？是什么应用环境？

ISCSI下普通网卡的TCP/IP的协议开销实际测试数据是多少呢？

[ 本帖最后由 Frank 于 2008-5-10 20:35 编辑 ]

Frank

引用:

原帖由 冬瓜头 于 2008-5-10 19:58 发表
还有个细节问题，如果是第二种方式，分配了inode等，不擦除原来的扇区内容，此时我如果要读取这个文件，那么读出来的是不是僵尸扇区，如何避免这种情况，是不是文件元数据保存一份文件自身的map信息来标记哪个offset ...

我理解是文件读写是文件系统来控制，和后端存储的LUN使用没直接关系。比如我删除了一个文件，LUN实际上并没有删除，只是inode（记不太清楚了，抱歉）某些位的变化。

peon

引用:

原帖由 冬瓜头 于 2008-5-10 19:41 发表
谢谢。再请教一下，如果一开始就分配好空间，这种方式自身有两种子模式：
1）设定长度但是不分配空间，也就是文件bitmap中全是“hole”，不指向硬盘扇区或者簇块。不需要大量磁盘IO
2）直接分配簇块，此时可以觉察 ...

有点没有明白 僵尸扇区 的意思，不过同意frank的观点

冬瓜头

frank，两码事，我又没说删除文件，更没说lun，就是请教peon文件系统层次的东西。

我做过一个试验，创建一个文件，然后设置成600MB的长度，没有大量IO。 用winhex打开这个文件，发现所有600MB数据全是0，所以问一下他这600MB的0是从哪里来的，如果指向实际扇区，那么不可能都是0，所以是不是还有一个文件级别的bitmap来掌控文件自身偏移处的块使用情况。

peon

冬瓜头是如何创建600MB文件的？ 是通过lseek操作么？我对于NT下的这种情况不是很熟悉。
LINUX/UNIX下，这种情况下文件系统中文件占用的字节大小和文件的长度是不一致的，也就是说文件的空洞并没有实际分配空间，假如read的话，读出来就是0