Thanks, that's an interesting review.
Happy to have 512 MB on my Nas.

using 5400 RPM drives with larges amounts of cache? Does this provide better price/performance?

Most of the artichle is spent on comparing the NAS'es and speculate on the effects of cache, and really gets funny when Firewire and Esata discs got into the test.

This article covers large file sizes very well, and does a good job explaining the value of the large cache for large file transfers, and this makes even more sense when the tester copies the same 32MB file 4 times in a row, nicely warming the cache for that transfer. I'm glad the RAM/cache info was included, as I was trying to puzzle out how the transfer rates could be so high for the Thecus.

I know I'm in the small minority, but I personally am more interested in using NAS for random access for millions of small accesses, so this benchmarking is probably not the best for me. It would be a lot more work, but I would love to see a firewire or Gigabit Enet NAS used to perform DB benchmarking. That would probably be an article in itself, but can a home NAS allow someone at home to use an architecture often used in midsized IT departments? Can a home NAS with a few HDDs in RAID 5 run as file server and DB server effectively, and with its own direct-attached backup system? The world may never know...

Like the first comment, I'm too very interrested on the performance on small files. For experimenting myself on a DNS-323, I can tell you that it's not very practical to transfert 16000 files of about 3-4Mo. After the transfert, the access of this NAS (I only own this one) is terribly slow compared to a real file server, it's a shame. What takes 45 minutes for a real computer (same HDD), took 5 hours for this NAS. I think I'll use it only for backup...

Good test and story -- as far as it goes. You wrote: "...If you are serving large media files (say, larger than a gigabyte), then no, the disk performance does not matter..."

However, this test really should be done with multiple RAID 1 (mirrored) drives and Gigabit Ethernet Jumbo Frames turned on. Contrary to your supposition in the story, I believe many NAS buyers who use these systems with new home theater systems and even for home digital imaging do use Jumbo Frames and do regularly work with 1GB and larger movie and layered Photoshop files.

So, I would think the performance of dual, RAID 1 Mirror drives with Jumbo Frames would be an equally important comparison. However, some NAS vendors may not have yet optimized their software for Jumbo Frames and all file systems.

The purpose of the test was to look at hard drive performance and whether it makes a difference for NAS performance. In order to do that, we needed to minimize caching effects, which is why large file sizes were used.

With small file sizes, OS and caching effects would have dominated performance and made it impossible to see any drive effects.

I've read a lot of articles like this and there is some good info here and Bill always does a thorough job (good job Bill!) There is more to consider IMO.
I'm curious to know why everyone seems so interested in Raid 0 and why they feel compelled to compare raid x performance to raid 0 performance. Its a useless comparison IMO. Sure raid 0 zips right along great until a hardware failure or data corruption occurs & then *poof* all data is lost. Now you're not zipping along and the price of that performance quadruples.

Raid 0 is NOT raid. Raid stand for REDUNDANT ARRAY of Inexpensive disks. There is NO/ZERO/NIL/NAUGHT redundancy in raid 0. (ok I'll get off the raid 0 soapbox)

2 things come to mind here. There was an excellent book written by Adrian Cockroft regarding system performance in the unix world. Good for understanding where the bottlenecks are between CPU, Cache, Ram, Disk, network, & OS. Some of the concepts still apply today and explain how to performance tune something. To me those kind of improvements will go farther than just adding more memory. (we always tend to want to throw more money at the problem than solve the problem)

Secondly, it might be time to revisit partitions. If someone is interested in a Raid system either BYO or off the shelf, partitioning it up in such a way as to get a performance boost from a raid0 temp area, a safe raid5, raid6, or raid1 area for critical data. Then these thing start to pay off. Yet performance tunning is still key.

An example for a perfect world: If I have small amounts of data, say thousands of tiny, 8k, files. Designing a raid that is relatively wide (more spindles) than it is deep (less disk space) I can get more performance by spreading out my data. If I then set my extent size to 8k, the same size as my data, then I don't lose any overhead in the process. If I set my extent size to 4k or 2k, it could be an improvement or a severe performance hit.

If I'm ripping DVD movies at 4GB each, then an extent size of 4k or 8k can be a problem and I want those to be as big as possible, say 4MB or bigger(1GB?). Also, I want that raid to be 'deeper' with more disk space, rather than wider. Breaking up 4GB of data across 4 disks is faster than breaking it up across 12 disks. Setting the stripe size (how much data is written to each disk) can also affect performance positively or negatively.

More spindles is wider, larger drives or partitions is deeper. Extent size is the size of the area data takes up, in unix systems its configurable, in windows it might not be, I don't know, I don't use windows. Hope this helps and I hope I remembered all this correctly, its been a few years since I looked it up.