On Apr 5, 2011, at 4:19 PM, rainer at ultra-secure.de wrote: > > >> But ... >> I've been reading about some of the issues with ZFS performance and have >> discovered that it needs a *lot* of RAM to support decent caching ... >> the recommendation is for a GByte of RAM per TByte of storage just for >> the metadata, which can add up. Maybe cache memory starvation is one >> reason why so many disappointing test results are showing up. > > Yes, it uses most of any available RAM as cache. > Newer implementations can use SSDs as a kind of 2nd-level cache ("L2-ARC"). > Also, certain on-disk logs can be written out to NVRAMs directly, speeding > up things even more. > Compared with Cache-RAM in RAID-Controllers, RAM for servers is dirt-cheap. > > The philosophy is: why put tiny, expensive amounts of RAM into the > RAID-controller and have it try to make guesses on what should be cached > and what not - if we can add RAM to the server directly at a fraction of > the cost and let the OS handle _everything_ short of moving the disk-heads > over the platters. The problem is the volatility of system RAM. Those very expensive RAID write-back caches are usually battery backed (if they aren't don't buy them). It's the battery and the technology to recover the write cache after failure that makes it so expensive. Look at the cost of capacitor backed SSDs vs non-capacitor backed SSDs. When I ran a ZFS NFS server I used a RAID controller with battery backed write-back cache and the ZIL spread across the pool. Even with each disk as RAID0 setup, it was able to perform just as well as a similar pool using a standard SAS controller and a good SSD drive but the SSD setup cost twice as much and unlike the SSD the NVRAM doesn't burnout or need trimming. > IMO, it's a brilliant concept. > > Do you know if there is a lot of performance-penalty with KVM/VBox, > compared to Solaris Zones? Solaris zones is not hardware virtualization it is a container technology like 'jail' or openvz but with resource management. -Ross