Frank

引用:

原帖由 冬瓜头 于 2008-5-10 22:23 发表
frank，两码事，我又没说删除文件，更没说lun，就是请教peon文件系统层次的东西。

我做过一个试验，创建一个文件，然后设置成600MB的长度，没有大量IO。 用winhex打开这个文件，发现所有600MB数据全是0，所以问一 ...

什么操作系统下创建的文件呢？如何创建的。

我的意思是，你看到的是通过文件系统看到的，还是在磁盘阵列管理软件看到的。2者看到的内容一般是不同的。

除了bitmap，还有很多方式可以管理blocks的使用。

hnull

关注ing

冬瓜头

引用:

原帖由 peon 于 2008-5-10 23:47 发表
冬瓜头是如何创建600MB文件的？ 是通过lseek操作么？我对于NT下的这种情况不是很熟悉。
LINUX/UNIX下，这种情况下文件系统中文件占用的字节大小和文件的长度是不一致的，也就是说文件的空洞并没有实际分配空间，假如 ...

create(),setlength() 就这两个函数，眨眼就完毕了。

hnull

冬瓜大哥啊能写详细点？
偶看不懂啊

saintdragon

比较底层的东西了。好好向各位学习

peon

刚才google了一下，关于iptv存储的文章大部分都是软文，基本上看了不着调的。还是自己总结一下吧：

电信级iptv系统的需求：
1. 大容量。2002年全国的电视节目制作量就是135115小时。每个小时假如是2Mbps码率，一小时节目就是900MB, 1万个小时就是9T, 一般来讲，电信采购最低最低也是1万个小时的存储，一般要求2万个小时以上，这个还是第一期的需求。
另外，出于冗余，性能和分布式的需求，实际使用的存储空间是初始空间的5-N倍(上不封顶)

2. 高吞吐，比方说1万个2Mbps VOD并发的话, 需要20Gbps的IO吞吐，这个并发还是比较小儿科的，真正的电信级iptv系统应该要支持百万以上的并发(国内至少还没有，国外应该也没有)。不过很多方案只在中心存储使用san等系统，这种情况下要求不高，这种情况对后面的需求也有类似影响

3. 高并发和低延迟，需要保证1万个以上的流的每个读写请求都可以在一定时间内完成，否则就会引起码流的抖动，影响用户观看

4. 分布式，不支持分布式部署的IPTV系统是个玩具。一个iptv系统要遍布多个地市的N多个机房，以实现用户的就近访问(可以参看CDN相应的知识)，所以存储也是分布式的。很多情况下需要架构多个分离的存储系统。

5. 可管理性

6. 低成本，电信运营商架设IPTV系统是要挣钱的，每个用户每个月只能收取20-100元不等，系统贵了，猴年马月才能收回成本......

7. 可扩展性，随着系统规模不断扩大，要求可以线性的扩展存储和性能

[ 本帖最后由 peon 于 2008-5-12 09:41 编辑 ]

冬瓜头

不知道电信的IPTV有没有使用组播，如果没有使用，主要原因在哪里，是不是因为终端部署组播成本太高。如果实现全网组播，那么后端流量压力是否会有减轻。这个就像dedupilcation一样。

peon

有使用组播的，组播是用来做直播频道的。
但是很多业务，比如vod 节目回看等，只能用单播

David.Lee

streaming 存储设计一直是架构方面的一个大问题，基本上有下面的几种选择：

1. 基于san的架构，这个成本比较高
2. 基于集群的主机+DAS ，这个其实还是蛮好做的，我02-04年呆的公司走的是这个路线，
3. 基于集群的主机+分布式文件系统，这个有点像群集+NAS了，但是NAS显然性能不够，这里的分布式文件系统是为streaming定制的，这个东西复杂性有点高，但是有极强的可伸缩性和性能


你好，前面你提到的那些技术我不懂，但是我看懂了你的存储架构，我看到第三个架构中提到“集群+NAS　”，不太清楚你说的性能不够是指的哪方面呢？我现在做一个美国的集群NAS产品“ISILON　”，个人认为这种产品应当会很合适你们的那个集群主机，如果你有兴趣可以去www.isilon.com去看看，那是官方网站，也许会对你有些帮助，在这里我就不多说了，不然又会被当做发广告的了。

没办法，这是新引进国内的技术，目前知道的人不多，所以一发贴子就被当做发广告的，如果说IBM，EMC，NETAPP的话，所有人都会认为是正常的。

冬瓜头

有没有某种算法比如计算出同一时刻点播某段相同视频的用户，或者时刻不完全相同，也可以在可允许的范围内适当增加几秒的等待时间之类，实现deduplication