Benchmarking Discussion
Benchmarking a NAS is a bit odd; it perforce involves more than just a single test machine, and many of the usual drive benchmarking tools don’t function well over a network. Raw device access is not relevant, because you’re never talking to the drives directly. The performance of the client computer’s network stack becomes a relevant factor, as does the quality of the cables and switches linking the client and NAS together.
All of this became immediately relevant to me when I noticed some oddities in large file transfer tests. A file would transfer to the NAS quickly, but afterwards it would pause for several seconds at a time, sometimes even minutes, before moving on to the next one. I tried searching around the Synology user forums, thinking this might be a firmware issue or a misconfiguration on my part, but nothing relevant appeared.
Broadening my search to the wider web, I ran across this article from Intel, which I believe points out the problem. You can follow the link if you want a full technical breakdown and performance comparison, but the basic issue is a difference in assumptions between the designers of NTFS and the designers of Ext4.
NTFS, like many file systems before it, pre-allocates space for all files before writing them to disk. To help prevent fragmentation, when the driver is asked to write a file, it issues little one byte writes to the allocated space at 128k intervals to mark the space as taken. This acts as a hint to the NTFS driver that it should reserve that space for the file in question while the write buffer is filling. Ext4, the underlying file system on all Synology NAS devices, uses an allocate-on-flush strategy, which holds off on allocating space for file blocks until it has a buffer-full of data to write all at once. Thus, it skips those little one byte pre-writes, as they are no longer necessary.
The problem occurs when a client system, such as the Windows 7 CIFS client, assumes that the shared volume on the NAS is a NTFS system, and thus issues those one byte pre-writes. Since Ext4 doesn’t normally do pre-allocation, it assumes that those writes are valid data, and allocates space accordingly. Later on, when the actual data is written, it has to go back and allocate space again. This usually leads to increased fragmentation, as the blocks it would have used are now chopped up into alternating one byte and 127 byte stretches.
Unfortunately, there is no easy solution to this conflict. Windows doesn’t natively understand any modern file systems other than NTFS and exFAT, neither of which use allocate-on-flush. Amending the Windows CIFS client to solve this issue would likely require a far larger investment of programmer time than Microsoft is willing to make.
There are a couple of ways of getting around this issue, both of which have drawbacks. A third party program could be used to talk to the NAS over NFS, but this requires purchasing additional software and additional time spent configuring it. Another solution would be to create an iSCSI target on the NAS, connect to it with Windows’ built in iSCSI initiator, and create a NTFS volume on it as you would with a local disk. This is a fairly robust solution for single user scenarios, but it makes sharing files among multiple users much more complicated.
For the purposes of this review, I chose the latter solution, and ran all of the benchmarks twice: once on the CIFS network share and once on the iSCSI target. Please note that this issue is specific to Windows clients in most cases; Linux and Mac OS do not use CIFS by default, and neither NFS nor WebDAV display this behavior.
Ah, this is so important to me.. hope to have one real soon..