After weeks of negotiations, IBM reportedly is eyeing a $9.55-per-share buyout for Sun Microsystems, according to a report in The Wall Street Journal. Such a price would value the deal at roughly $7 billion and offer Sun investors nearly double the price of the stock before reports surfaced earlier this month that the parties are in buyout talks. A report in The New York Times, meanwhile, notes the parties are discussing a purchase price of $9.50 a share. In either case, Sun's investors haven't seen the hardware maker's stock trade at those levels since August. Last spring, Sun was trading at a 52-week high of $16.37 a share.

But my concrete question, which no one has deigned to answer, is "where is the memory going in ZFS?".

I wish some ZFS advocate would simply answer the question instead of dodging it or claiming that it was not an issue.

ZFS would like to use a lot of memory, true. But it doesn't require it. It doesn't use it to implement some feature. It wants to use it for caching data. Out of the box, ZFS sets it maximum caching to 7/8th of the total of your memory, yes you can tune this to a lower number, but unless you know your application very well and do extensive real world benchmarking using your appplication you usually end up making the system slower. If you have 8GB of memory in your server ZFS will use 7GB of it for caching your data. No ZFS doesn't demand it, it requests it, and the OS is free to take it back for other uses should it decide that your application would benefit from using the memory rather than of ZFS.

Of course some would say that this is too much memory. But remember every block of data that is retrived from cache instead of disk is 1000x faster. So is a big win for the user. Even if ZFS keeps its cache in memory instead of an application its still a big win, a typical hard disks can pull in 50MB of data from the disk in the time it takes the user to switch to a new window and type a word.

ZFS is very good at prefeching data and tracking data that is cached, not only can it track multiple streams of data being synchronously read, and prefetch accordingly. It also tracks of blocks of data that were removed from cache and then needed so to better guess what data is going to be needed soon and keep it in the cache. Most other filesystems aren't smart enough to see multiple users steaming more than one file and takes there traffic pattern as random and not prefetching the data for them.

ZFS is large by kernel standards, perhaps a few MB of kernel memory but these days that is not an issue, no you can't pick and choose ZFS features to disable hoping to save space these days its not an an issue, Everyone that complains about its memory use issue is reacting to its caching of data and most of this comes from users that are used to not seeing how much data the filesystem is caching, in top its usually just an entry in the system memory line "cached: 50000k" and no buddy cares, but when they see it associated with a filesystem everyone panics.

If you are using ZFS on Solaris you can use this cool new tool fsstat to see just how fast ZFS really is, because of the extensive caching of data, tradional tools like iostat aren't effective in monitoring how much data it is serving. I typically see 200MB/s from my ZFS fileserver (4x 500GB sata disks in a raidz pool), I have seen numbers as high as 500MB/s which is close to the maximum streaming bandwidth of the hard disks typically seen in artificial benchmarks.

Yes ZFS + Solaris needs about 1GB to minimum to be happy, but that is about $10 in today's market don't have at least 1GB of ram go collect aluminum cans and buy some memory, and ZFS will use all it can get. I have heard of people being happy with 512MB, which is possible if you have low needs and a high tolerance for sluggishness. But even with all this ZFS delivers features that set it apart from anything else out there, once you get used to snapshots and clones you will wonder how you ever managed to live without them.