VOD基本上是讀一個固定的檔案,要避開seek的問題還算不難,DVR是寫入一個或以上會隨時間長大的大檔案(除非先將各stream多工以TS的型式寫入單一檔案,但後續的播放/seek等等會比錄成分開的PS麻煩),throughput是還好(2xMB/sec對現代的HD實在不算什麼,讀寫單一stream要破60MB/sec不是啥難事),機械性seek的問題會比VOD嚴重,就算是錄16ch MPEG1也會遇到同樣的問題,只是MPEG1流量較低(不像MPEG2輕而易舉就能把HD的cache塞爆了),cache再配上NCQ之類應該有所助益....BTW,您的測試方向是對的,但樣品有點問題(不夠大),比較容易受其它誤差影響,改大點(ex 16*100MB)應該會比較精確,不過對HD而言就是殘酷的考驗了(i.e.除非這個HD是食之無味,棄之可惜的雞肋,不然這類遊戲沒事還是別亂玩的好)....

我可能沒講清楚
16個process是不斷寫入直到檔案有10GB
能寫多快就寫多快
總共寫入速度是20MB/sec
# cat mytest
[ ! -d test ] && mkdir test
declare -i x
x=0
while [ 1 ]
do
x=$x+1
cat test_001m.zip >> test/test.$1
[ $x -eq 10000 ] && x=0 && rm -f test/test.$1
done

#for(( i=1; $<=16 ; i=$i+1)) do; ./mytest $i & ; done

原來如此.....那測試時HD有沒有慘叫連連啊....

如果分成16台會比較符合VOD的需求

補充一下,作這類測試的storage最好在mount時把sync和atime關掉(一般default就是async,但atime要用noatime關掉),對throughput和HD能否長命百歲多少有點幫助....

從數據上看不出throughput有提升

那可能就真的是極限了,以上兩點只是盡可能減少filesystem的overhead(反正VOD上的檔案不見得很重要,不過DVR就難說了),榨不出油水的還是榨不出來就是了....

調整寫入快取....

但相對於16ch MPEG stream的throughput而言storage的overall performance要到啥程度NCQ/cache才有機會發揮作用?? 如果能把16ch MPEG stream合併成一路TS(鵝不清楚是否可行),一次只寫單一檔案應該會好些(track to track seek vs random seek),只是CPU要多快就難說了....BTW,錄成單一TS時對播放/剪接比較麻煩(牽一髮而動全身),但對DVR而言或許不是好事(增加造假的難度)....