Single Client Performance - CIFS & NFS on Linux

A CentOS 6.2 virtual machine was used to evaluate NFS and CIFS performance of the NAS when accessed from a Linux client. We chose IOZone as the benchmark for this case. In order to standardize the testing across multiple NAS units, we mount the CIFS and NFS shares during startup with the following /etc/fstab entries.

//<NAS_IP>/PATH_TO_SMB_SHARE /PATH_TO_LOCAL_MOUNT_FOLDER cifs rw,username=guest,password= 0 0

<NAS_IP>:/PATH_TO_NFS_SHARE /PATH_TO_LOCAL_MOUNT_FOLDER nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2, sec=sys,mountaddr <NAS_IP>,mountvers=3,mountproto=udp,local_lock=none,addr=<NAS_IP> 0 0

The following IOZone command was used to benchmark the CIFS share:


IOZone provides benchmark numbers for a multitude of access scenarios with varying file sizes and record lengths. Some of these are very susceptible to caching effects on the client side. This is evident in some of the graphs in the gallery below.

Readers interested in the hard numbers can refer to the CSV program output here.

The NFS share was also benchmarked in a similar manner with the following command:

IOZone -aczR -g 2097152 -U /nfs_test_mount/ -f /nfs_test_mount/testfile -b <NAS_NAME>_NFS_EXCEL_BIN.xls > <NAS_NAME>_NFS_CSV.csv

The IOZone CSV output can be found here for those interested in the exact numbers.

A summary of the bandwidth numbers for various tests averaged across all file and record sizes is provided in the table below. As noted previously, some of these numbers are skewed by caching effects. A reference to the actual CSV outputs linked above make the entries affected by this effect obvious.

ioSafe 1513+ - Linux Client Performance (MBps)
Init Write 68 66
Re-Write 68 73
Read 34 123
Re-Read 35 123
Random Read 20 59
Random Write 62 73
Backward Read 19 46
Record Re-Write 38 1300*
Stride Read 31 105
File Write 68 77
File Re-Write 68 78
File Read 24 92
File Re-Read 24 92
*: Number skewed due to caching effect


Single Client Performance - CIFS & iSCSI On Windows Multi-Client Performance - CIFS


View All Comments

  • ganeshts - Wednesday, August 13, 2014 - link

    I hope we don't have readers chiming in about how they can build a better DIY NAS than the one presented here :) Reply
  • hodakaracer96 - Wednesday, August 13, 2014 - link

    I for one, was hoping for fire and water testing :) Reply
  • Samus - Wednesday, August 13, 2014 - link

    Some good "tests" on youtube:
  • ddriver - Thursday, August 14, 2014 - link

    I wouldn't bet money on this product surviving an actual fire. Insulation seems too thin Reply
  • ganeshts - Friday, August 15, 2014 - link

    I hope you are kidding :) ioSafe's products have been proven to work - they have many real world success stories. Quite sure they can't have big-name customers if they don't prove that they can really protect the drives as per the disaster specifications quoted. Just for reference, a picture of one of the 1513+ units subject to both fire and water damage is in our CES coverage: Reply
  • ddriver - Friday, August 15, 2014 - link

    Well, looking at the youtube videos of fire test I am not really impressed. Surely, it will probably survive a mild and short fire with not much material to burn, but being in a serious blaze and buried in blowing embers it will not last long. A regular NAS unit put in a small concrete cellar with no flammable materials in it has better chances of surviving.

    And this probably has to do with how they test their products, which I can logically assume is safe controlled fires carefully estimated to not exceed the theoretical damage the unit can handle. But how many houses did they torch to test their products in real life disaster situations? My guess is zero :)
  • ddriver - Friday, August 15, 2014 - link

    I mean, it will most likely survive a plastic trash can full of paper catching fire and burning out next to it, but will it survive an actual blaze disaster? I highly doubt it.

    In other words, I don't doubt the product will survive what they claim it can survive, I doubt that the disaster specifications they quote reflect real world fire disasters well enough. They will probably suffice for "fire accidents" but not really in "fire disasters".
  • ganeshts - Friday, August 15, 2014 - link

    Does this convince you?

    As for real-life situations, they are claiming protection for the following fire situation: 1550°F, 30 minutes per ASTM E-119

    I remember reading a post about some statistics regarding how fast fire services respond to hourhold fires, and ioSafe's protection circumstances fall within that. Anyways, this product is targeted at SMBs / SMEs who have buildings as per fire marshal codes. Any blaze in such a situation is probably going to be controlled well by building sprinklers.
  • ddriver - Friday, August 15, 2014 - link

    It is the 1550 F number that bothers me. That's below 850 C, and even wood and plastic burns at almost 2000 C using air as oxidizer. Most of the stuff that is flammable burns around 1950 C, so targeting the product at 850 C pretty much excludes direct fire damage. E.g. if you have a wooden cabin and if it burns to the ground, the data is very unlikely to recover.

    That is why I drew a line between "accident" and "disaster". This product will do in the case of fire accidents, but in the case of a fire disaster its specs are just not enough.

    So, it is a "fireproof" product for buildings with anti-fire sprinkler installations and with good accessibility for fire services. In short, it doesn't protect in the case of fire disasters, but in the case of fire accidents and the water used to put them out.
  • robb.moore - Friday, August 15, 2014 - link

    Hi ddriver-
    The average cellulose building fire temps are between 800-1000F for about 10-15 minutes. We've been in many fires and have a record or zero data loss for fire disasters in the real world. Most of the building damage is actually caused by firefighter hoses - not the actual fire. The absolute temperature (1500, 1700, 2000...) is not as important as the duration actually. Think of a pot of water boiling on the stove - as long as there's water in the pot, the pot doesn't melt because the endothermic action of the boiling water (212F) keeps the pot from melting. The flame temp could be anywhere between 800 and 3000+? and the water would still boil at 212F (assuming sea level pressures). You could use an aluminum pot (which melts at 1100) and still be ok. Once the water runs dry, then you'll ruin the pot. It's actually the same with all fire safes (and ioSafe). There's water chemically bound to the insulation that works to cool the inner chamber and keeps it at survival temps. Our fire test standards is hotter and longer than typical building fires and the systems we sell typically can go double the standard just to be conservative.

    The fire protection technology is not new. We use the same proven techniques that have been around for 100 years. What unique about ioSafe is how we combine fire/water protection with active computers – managing the heat produced during normal operation while protecting against extreme heat possible during a disaster.

    As Ganesh has said, we test both internally and externally (with the press watching and recording!) in both standard and (ahem) very non-standard ways at times - we've NEVER failed a demo. One of these days, I'm sure a gremlin's gonna pop up and we'll get recorded by the press as failing a disaster demo (because a HDD refuses to boot) but that's the risk we take. Our stuff's legit.

    And btw, a cellar is a great place for tornados and fires but not so good for water main breaks or river floods – we’ve seen it all :)

    Robb Moore, CEO
    ioSafe Inc.

Log in

Don't have an account? Sign up now