Tim writes: > On Sat, Nov 29, 2008 at 11:06 AM, Ray Clark <[EMAIL PROTECTED]>wrote: > > > Please help me understand what you mean. There is a big difference between > > being unacceptably slow and not working correctly, or between being > > unacceptably slow and having an implementation problem that causes it to > > eventually stop. I expect it to be slow, but I expect it to work. Are you > > saying that you found that it did not function correctly, or that it was > > too > > slow for your purposes? Thanks for your insights! (3x would be awesome). > > -- > > > > > > I expect it will go SO SLOW, that some function somewhere is eventually > going to fail/timeout. That system is barely usable WITHOUT compression. I > hope at the very least you're disabling every single unnecessary service > before doing any testing, especially the GUI. > > ZFS uses ram, and plenty of it. That's the nature of COW. Enabling > realtime compression with an 800mhz p3? Kiss any performance, however poor > it was, goodbye. > > --Tim
Hi Tim, Let me highjack this thread to comment on the RAM usage. It's a misconception to blame ram usage on COW. As been stated in this threads, ZFS will need Address Space in the kernel in order to maintain it's cache. But the cache is designed to grow and shrink according to memory demand. The amount memory that ZFS really _needs_ is the amount of dirty data per transaction group. Today the code is in place to limit that to 10 seconds worth of I/O. So this should be very reasonable usage in most cases. -r _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
