In any case, I would suggest posting your queries on ns-3-users so that a wider audience is available to answer them.

About writing scenario files, I suggest starting with an existing example script always, and modifying it incrementally till you get what you want. Have a look within examples/ and src//examples/ and experiment a bit with the existing simulation scripts to get a feel of things.

i worked before with ns-2 but now i change my simulator but i have problem with ns-3
i have read the tutorial but is not so clear in some part like tracing system.

do you have any suggestion for continuing in ns-3.
about writing scenario and getting result from output.

Your work is very nice! Moving complex metadata operations to a database simplify the NameNode design and implementation. However, the metadata latency and throughput might be impacted by the backend MySQL Cluster. Looking forward for your future works!

We have addressed the availability issue of HDFS in Clover. In my recent presentation in Hadoop in China 2011, I talked about using BackupNodes in Clover NameNode Cluster to get a highly available metadata service.
Here is the link (Chinese Version):http://hic2011.hadooper.cn/dct/attach/Y2xiOmNsYjpwZGY6MTQxMzI=
I will put an English version to posterous in a few days:-)

BTW: There is a similar work from Taobao.com in China, please refer to the following presentation(Chinese):
http://hic2011.hadooper.cn/dct/attach/Y2xiOmNsYjpwZGY6MTQxODQ=

You are correct in pointing out that there is a higher latency involved in our implementation. But bear in mind that HDFS is optimised for throughput, not latency. It doesn’t matter how long an individual operation takes as long we can have a whole bunch of operations being executed per second in the cluster.

Further note that operations in HDFS are data intensive, not metadata intensive. Let’s consider a client trying to simply read a file named “foo” of size 10GB from HDFS. Assume that the blocks are of size 512MB (implying that we have 20 blocks in total). The client first asks the Namenode for the list of blocks corresponding to the file “foo”. The HDFS Namenode would return this list in around 1ms, the KTHFS one would take around 10-20ms in our not-so-optimised-version now, but let’s put it at 100ms even. The client then proceeds to read 10GB of data from the Datanodes over a course of several minutes. So the 100ms latency that we add to the meta-data operation is pretty much shadowed by the duration of the normal data-operation. The latter remains unaffected from the normal HDFS, and is in the order of minutes.

Again, since throughput is the key, not latency, we can add more and more Namenodes in KTHFS to increase the overall number of metadata operations per second that can be executed. Even at this stage of development, we have linear scalability on the number of operations per second for write intensive workloads. So it’s not only about high availability, it’s also about scaling out.

Like I said, we’re still far away from getting the most out of this design, and are on our way to map the Namenode internals better to the kind of DB operations we’re doing. And by the way, “over the wire” on the cluster here at SICS is around 0.1ms.