[zfs-discuss] Monitoring zfs using dtrace
Apologies for cross posting but I have been looking at the probes fired when a snapshot is created. I get pa...@openindiana:~/programming/dtrace$ pfexec ./snapshots.d dtrace: script './snapshots.d' matched 54 probes CPU IDFUNCTION:NAME 0 37478 zfs_secpolicy_snapshot:entry 0 39588 zfs_secpolicy_snapshot_perms:entry 0 39589 zfs_secpolicy_snapshot_perms:return 0 37479zfs_secpolicy_snapshot:return 0 37614 zfs_ioc_snapshot:entry 0 39426 snapshot_namecheck:entry 0 39427snapshot_namecheck:return 0 40262dmu_objset_snapshot:entry 0 36158dmu_objset_snapshot_one:entry 0 36159 dmu_objset_snapshot_one:return 0 36154 snapshot_check:entry 0 38072 dsl_dataset_snapshot_check:entry 0 36312 dsl_dataset_snapshot_reserve_space:entry 0 36313 dsl_dataset_snapshot_reserve_space:return 0 38073 dsl_dataset_snapshot_check:return 0 36155snapshot_check:return 1 36154 snapshot_check:entry 1 38072 dsl_dataset_snapshot_check:entry 1 36312 dsl_dataset_snapshot_reserve_space:entry 1 36313 dsl_dataset_snapshot_reserve_space:return 1 38073 dsl_dataset_snapshot_check:return 1 36155snapshot_check:return 1 36156 snapshot_sync:entry 1 37952 dsl_dataset_snapshot_sync:entry 1 39738dsl_scan_ds_snapshotted:entry 1 39739 dsl_scan_ds_snapshotted:return 1 37953 dsl_dataset_snapshot_sync:return 1 36157 snapshot_sync:return 1 40263 dmu_objset_snapshot:return 1 37615 zfs_ioc_snapshot:return Matching entry to return there seems to be two stages check permissions then create. The creation seems to be wrapped by zfs_ioc_snapshot:entry/return There are probes for pool and zfs filesystem creations which include the word create (zfs_create_fs and zfs_ioc_pool_create) , any idea why snapshots are treated differently? Cheers Paul -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Bob Friesenhahn wrote: It seems like this Nagios script is not very useful since the notion of free memory has become antiquated. Not true. The script is simply not intelligent enough. There are really 3 broad kinds of RAM usage: A) Unused B) Unfreeable by the kernel (normal process memory) C) Freeable by the kernel (buffer cache, ARC, etc.) Monitoring usually should focus on keeping (A+C) above some threshold. On Solaris, this means parsing some rather obscure kstats, sadly (not that Linux's /proc/meminfo is much better). Or has vmstat grown more intelligence when I wasn't looking? -- Carson ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
On Wed, May 6, 2009 at 10:17 PM, Richard Elling richard.ell...@gmail.com wrote: Fajar A. Nugraha wrote: IMHO it's probably best to set a limit on ARC size and treat it like any other memory used by applications. There are a few cases where this makes sense, but not many. The ARC will shrink, as needed. With the new write throttle, the perception of ARC dominance is significantly reduced. The main reason to limit ARC today, is to prevent the large page/small page change that can happen if you need to restart a large-page using application (eg databases). I got a recommendation to limit ARC size when using zfs in xen dom0. https://opensolaris.org/jive/thread.jspa?messageID=355579 Is it among the not many cases, or is irrelevant today with new write throttle? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Fajar A. Nugraha wrote: On Wed, May 6, 2009 at 10:17 PM, Richard Elling richard.ell...@gmail.com wrote: Fajar A. Nugraha wrote: IMHO it's probably best to set a limit on ARC size and treat it like any other memory used by applications. There are a few cases where this makes sense, but not many. The ARC will shrink, as needed. With the new write throttle, the perception of ARC dominance is significantly reduced. The main reason to limit ARC today, is to prevent the large page/small page change that can happen if you need to restart a large-page using application (eg databases). I got a recommendation to limit ARC size when using zfs in xen dom0. https://opensolaris.org/jive/thread.jspa?messageID=355579 Is it among the not many cases, or is irrelevant today with new write throttle? I see no justification in that post for limiting memory use. You can easily measure memory usage with vmstat and ARC-specific usage with arcstat and see if you are running into a memory shortfall. If not, then the recommendation may be misguided. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Carson Gaspar wrote: Not true. The script is simply not intelligent enough. There are really 3 broad kinds of RAM usage: A) Unused B) Unfreeable by the kernel (normal process memory) C) Freeable by the kernel (buffer cache, ARC, etc.) Monitoring usually should focus on keeping (A+C) above some threshold. On Solaris, this means parsing some rather obscure kstats, sadly (not that Linux's /proc/meminfo is much better). B) is freeable but requires moving pages to spinning rust. There's a subset of B (Call it B1) that is the active processes' working sets which are basically useless to swap out, since they'll be swapped right back in again. Two other important types of RAM usage in many modern situations: D) Unpageable (pinned) memory E) Memory that is presented to the OS but that is thin-provisioned by a hypervisor or other vitualization layer. (use of this memory may mean that the hypervisor moves pages to spinning rust) For virtualized systems, you should limit the size of A+B1+C so that it does not get into memory E. There's no point in having data in the ARC if the hypervisor has to go to disk to get it. Considering that the size of E is dependant on the memory demands on the host server, (which the guest has no insight into) this is a Very Hard problem. Often this is arranged by having the hypervisor break the virtualization containment via a memory management driver (vmware tools provides a memory control, for example) which steals pages of virtual-chip memory to avoid the hypervisor swapping. --Joe ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
On Thu, 7 May 2009, Moore, Joe wrote: Carson Gaspar wrote: Not true. The script is simply not intelligent enough. There are really 3 broad kinds of RAM usage: A) Unused B) Unfreeable by the kernel (normal process memory) C) Freeable by the kernel (buffer cache, ARC, etc.) Monitoring usually should focus on keeping (A+C) above some threshold. On Solaris, this means parsing some rather obscure kstats, sadly (not that Linux's /proc/meminfo is much better). B) is freeable but requires moving pages to spinning rust. There's a subset of B (Call it B1) that is the active processes' working sets which are basically useless to swap out, since they'll be swapped right back in again. Yes. Solaris memory use is much more complex than can be described by simple A, B, C. Using pmap on a running process reveals this complexity, yet this only shows the complexity from a process's view, and excludes usages such as zfs ARC. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Monitoring ZFS host memory use
Hi, Please forgive me if my searching-fu has failed me in this case, but I've been unable to find any information on how people are going about monitoring and alerting regarding memory usage on Solaris hosts using ZFS. The problem is not that the ZFS ARC is using up the memory, but that the script Nagios is using to check memory usage simply sees, say 96% RAM used, and alerts. The options I can see, and the risks I see with them, are: 1) Raise the alert thresholds so that they are both (warn and crit) above the maximum that the ARC should let itself be. The problem is I can see those being in the order of 98/99% which doesn't leave a lot of room for response if memory usage is headed towards 100%. 2) Alter the warning script to ignore the ARC cache and do alerting based on what's left. Perhaps with a third threshold somewhere above where the ARC should let things get, in case for some reason the ARC isn't returning memory to apps. The risk I see here is that ignoring the ARC may present other odd scenarios where I'm essentially ignoring what's causing the memory problems. So how are others monitoring memory usage on ZFS servers? I've read (but can't find a written reference) that the ARC limits itself such that 1GB of memory is always free. Is that a hard coded number? Is there a bit of leeway around it or can I rely on that exact number of bytes being free unless there is impending 100% memory utilisation? Regards, TROY NANCARROW Systems Architect - UNIX Systems T +61 (3) 8325 2454 1-21 Dean Street, Moonee Ponds, VIC, 3039 www.foxtel.com.au http://www.foxtel.com.au/ This e-mail, and any attachment, is confidential. If you are not the intended recipient, please delete it from your system, do not use or disclose the information in any way, and notify the sender immediately. Any views expressed in this message are those of the individual sender and may not be the views of FOXTEL, unless specifically stated. No warranty is made that the e-mail or attachment (s) are free from computer viruses or other defects. FOXTELemail_footer.gif___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
On Wed, May 6, 2009 at 1:08 PM, Troy Nancarrow (MEL) troy.nancar...@foxtel.com.au wrote: So how are others monitoring memory usage on ZFS servers? I think you can get the amount of memory zfs arc uses with arcstat.pl. http://www.solarisinternals.com/wiki/index.php/Arcstat IMHO it's probably best to set a limit on ARC size and treat it like any other memory used by applications. Regards, Fajar ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Troy Nancarrow (MEL) schrieb: Hi, Please forgive me if my searching-fu has failed me in this case, but I've been unable to find any information on how people are going about monitoring and alerting regarding memory usage on Solaris hosts using ZFS. The problem is not that the ZFS ARC is using up the memory, but that the script Nagios is using to check memory usage simply sees, say 96% RAM used, and alerts. The options I can see, and the risks I see with them, are: 1) Raise the alert thresholds so that they are both (warn and crit) above the maximum that the ARC should let itself be. The problem is I can see those being in the order of 98/99% which doesn't leave a lot of room for response if memory usage is headed towards 100%. 2) Alter the warning script to ignore the ARC cache and do alerting based on what's left. Perhaps with a third threshold somewhere above where the ARC should let things get, in case for some reason the ARC isn't returning memory to apps. The risk I see here is that ignoring the ARC may present other odd scenarios where I'm essentially ignoring what's causing the memory problems. So how are others monitoring memory usage on ZFS servers? I've read (but can't find a written reference) that the ARC limits itself such that 1GB of memory is always free. Is that a hard coded number? Is there a bit of leeway around it or can I rely on that exact number of bytes being free unless there is impending 100% memory utilisation? Regards, *TROY NANCARROW* the ZFS evil tuning guide contains a description how to limit the arc size. Look here: http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Solaris_10_8.2F07_and_Solaris_Nevada_.28snv_51.29_Releases Concerning monitoring of ARC size, I use (of course) my own tool called sysstat. It shows all key system metrics on one terminal page similar to top. You can get it there: http://www.maier-komor.de/sysstat.html HTH, Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Fajar A. Nugraha wrote: On Wed, May 6, 2009 at 1:08 PM, Troy Nancarrow (MEL) troy.nancar...@foxtel.com.au wrote: So how are others monitoring memory usage on ZFS servers? I think you can get the amount of memory zfs arc uses with arcstat.pl. http://www.solarisinternals.com/wiki/index.php/Arcstat arcstat is a perl script which reads the ARC kstats (mainly because there is a nifty perl module which reads kstats, which is why /usr/bin/kstat is written in perl). You can always do similar. IMHO it's probably best to set a limit on ARC size and treat it like any other memory used by applications. There are a few cases where this makes sense, but not many. The ARC will shrink, as needed. With the new write throttle, the perception of ARC dominance is significantly reduced. The main reason to limit ARC today, is to prevent the large page/small page change that can happen if you need to restart a large-page using application (eg databases). -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
On Wed, 6 May 2009, Troy Nancarrow (MEL) wrote: Please forgive me if my searching-fu has failed me in this case, but I've been unable to find any information on how people are going about monitoring and alerting regarding memory usage on Solaris hosts using ZFS. The problem is not that the ZFS ARC is using up the memory, but that the script Nagios is using to check memory usage simply sees, say 96% RAM used, and alerts. Memory is meant to be used. 96% RAM use is good since it represents an effective use of your investment. In the old days there was concern if an application or application's data could fit in RAM, or that if there was a shortage of RAM, then there could be a lot of activity on the swap device and the system would slow to a crawl. Nowadays RAM in server applications is primarily used as cache. It could be caching application executable pages, shared library executable pages, memory mapped file pages, and normal filesystem data. Caching is good so if a busy server shows a lot of memory free, then perhaps someone wasted money purchasing more RAM than was needed. Or perhaps this extra memory is in reserve for that unusual high load day. If there is insufficient RAM, there may still be 96% RAM in use, but since there is less useful caching, other metrics such as hard paging rates or disk access rates may go up, leading to a slow system. It seems like this Nagios script is not very useful since the notion of free memory has become antiquated. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Bob Friesenhahn wrote: On Wed, 6 May 2009, Troy Nancarrow (MEL) wrote: Please forgive me if my searching-fu has failed me in this case, but I've been unable to find any information on how people are going about monitoring and alerting regarding memory usage on Solaris hosts using ZFS. The problem is not that the ZFS ARC is using up the memory, but that the script Nagios is using to check memory usage simply sees, say 96% RAM used, and alerts. Memory is meant to be used. 96% RAM use is good since it represents an effective use of your investment. Actually, I think a percentage of RAM is a bogus metric to measure. For example, on a 2TBytes system, you would be wasting 80 GBytes. Perhaps you should look for a more meaningful threshold. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
On Wed, 6 May 2009, Richard Elling wrote: Memory is meant to be used. 96% RAM use is good since it represents an effective use of your investment. Actually, I think a percentage of RAM is a bogus metric to measure. For example, on a 2TBytes system, you would be wasting 80 GBytes. Perhaps you should look for a more meaningful threshold. So percent of memory consumed is not a useful efficiency metric? Is this true even if a double precision floating point value is used? :-) It seems like a more useful measure (on a server) is a caching efficiency metric. If the cache hit ratios are poor yet the cache is continually being loaded with new data, then there may be a resource availability issue. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS host memory use
Ben Rockwood's written a very useful util called arc_summary: http://www.cuddletech.com/blog/pivot/entry.php?id=979 It's really good for looking at ARC usage (including memory usage). You might be able to make some guesses based on kstat -n zfs_file_data and kstat -n zfs_file_data_buf. Look for mem_inuse. Running ::memstat in mdb -k also shows Kernel memory usage (probably includes ZFS overhead) and ZFS File Data memory usage. But it's painfully slow to run. kstat is probably better. -Paul Choi Richard Elling wrote: Bob Friesenhahn wrote: On Wed, 6 May 2009, Troy Nancarrow (MEL) wrote: Please forgive me if my searching-fu has failed me in this case, but I've been unable to find any information on how people are going about monitoring and alerting regarding memory usage on Solaris hosts using ZFS. The problem is not that the ZFS ARC is using up the memory, but that the script Nagios is using to check memory usage simply sees, say 96% RAM used, and alerts. Memory is meant to be used. 96% RAM use is good since it represents an effective use of your investment. Actually, I think a percentage of RAM is a bogus metric to measure. For example, on a 2TBytes system, you would be wasting 80 GBytes. Perhaps you should look for a more meaningful threshold. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Monitoring ZFS Statistic
By combining two great tools arcstat and dimstat you can get ZFS statistics in: * table view * chart view * any date/time interval * host to host compare For example, online table and chart view Ream more here http://blogs.sun.com/pomah/entry/monitoring_zfs_statistic -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS
The latency issue might improve with this rfe 6471212 need reserved I/O scheduler slots to improve I/O latency of critical ops -r Tom Duell writes: Group, We are running a benchmark with 4000 users simulating a hospital management system running on Solaris 10 6/06 on USIV+ based SunFire 6900 with 6540 storage array. Are there any tools for measuring internal ZFS activity to help us understand what is going on during slowdowns? We have 192GB of RAM and while ZFS runs well most of the time, there are times where the system time jumps up to 25-40% as measured by vmstat and iostat. These times coincide with slowdowns in file access as measured by a side program that simply reads a random block in a file... these response times can exceed 1 second or longer. Any pointers greatly appreaciated! Tom !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1 title/title /head body text=#00 bgcolor=#ff font face=Helvetica, Arial, sans-serifGroup,br br We are running a benchmark with 4000 usersbr simulating a hospital management systembr running on Solaris 10 6/06 on USIV+ basedbr SunFire 6900 with 6540 storage array.br br Are there any tools for measuring internalbr ZFS activity to help us understand what is going br on during slowdowns?br br We have 192GB of RAM and while ZFS runsbr well most of the time, there are times wherebr the system time jumps up to 25-40%br as measured by vmstat and iostat.nbsp; Thesebr times coincide with slowdowns in file accessbr as measured by a side program that simplybr reads a random block in a file... these responsebr times can exceed 1 second or longer.br br Any pointers greatly appreaciated!br br Tombr br br /font /body /html ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] Monitoring ZFS
Hello Neil, Wednesday, December 13, 2006, 1:59:15 AM, you wrote: NP Tom Duell wrote On 12/12/06 17:11,: Group, We are running a benchmark with 4000 users simulating a hospital management system running on Solaris 10 6/06 on USIV+ based SunFire 6900 with 6540 storage array. Are there any tools for measuring internal ZFS activity to help us understand what is going on during slowdowns? NP dtrace can be used in numerous ways to examine NP every part of ZFS and Solaris. lockstat(1M) (which actually NP uses dtrace underneath) can also be used to see the cpu activity NP (try lockstat -kgIW -D 20 sleep 10). NP You can also use iostat (eg iostat -xnpcz) to look at disk activity. It's bad that IO provider doesn't work with ZFS :( -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Monitoring ZFS
Group, We are running a benchmark with 4000 users simulating a hospital management system running on Solaris 10 6/06 on USIV+ based SunFire 6900 with 6540 storage array. Are there any tools for measuring internal ZFS activity to help us understand what is going on during slowdowns? We have 192GB of RAM and while ZFS runs well most of the time, there are times where the system time jumps up to 25-40% as measured by vmstat and iostat. These times coincide with slowdowns in file access as measured by a side program that simply reads a random block in a file... these response times can exceed 1 second or longer. Any pointers greatly appreaciated! Tom ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS
Tom Duell wrote On 12/12/06 17:11,: Group, We are running a benchmark with 4000 users simulating a hospital management system running on Solaris 10 6/06 on USIV+ based SunFire 6900 with 6540 storage array. Are there any tools for measuring internal ZFS activity to help us understand what is going on during slowdowns? dtrace can be used in numerous ways to examine every part of ZFS and Solaris. lockstat(1M) (which actually uses dtrace underneath) can also be used to see the cpu activity (try lockstat -kgIW -D 20 sleep 10). You can also use iostat (eg iostat -xnpcz) to look at disk activity. We have 192GB of RAM and while ZFS runs well most of the time, there are times where the system time jumps up to 25-40% as measured by vmstat and iostat. These times coincide with slowdowns in file access as measured by a side program that simply reads a random block in a file... these response times can exceed 1 second or longer. ZFS commits transaction groups every 5 seconds. I suspect this flurry of activity is due to that. Commiting can indeed take longer than a second. You might be able to show this by changing it with: # echo txg_time/W 10 | mdb -kw then the activity should be longer but less frequent. I don't however recommend you keep it at that value. Any pointers greatly appreaciated! Tom ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Monitoring ZFS
Thanks, Neil, for the assistance. Tom Neil Perrin wrote On 12/12/06 19:59,: Tom Duell wrote On 12/12/06 17:11,: Group, We are running a benchmark with 4000 users simulating a hospital management system running on Solaris 10 6/06 on USIV+ based SunFire 6900 with 6540 storage array. Are there any tools for measuring internal ZFS activity to help us understand what is going on during slowdowns? dtrace can be used in numerous ways to examine every part of ZFS and Solaris. lockstat(1M) (which actually uses dtrace underneath) can also be used to see the cpu activity (try lockstat -kgIW -D 20 sleep 10). You can also use iostat (eg iostat -xnpcz) to look at disk activity. Yes, we are doing this and the disks are performing extremely well. We have 192GB of RAM and while ZFS runs well most of the time, there are times where the system time jumps up to 25-40% as measured by vmstat and iostat. These times coincide with slowdowns in file access as measured by a side program that simply reads a random block in a file... these response times can exceed 1 second or longer. ZFS commits transaction groups every 5 seconds. I suspect this flurry of activity is due to that. Commiting can indeed take longer than a second. You might be able to show this by changing it with: # echo txg_time/W 10 | mdb -kw then the activity should be longer but less frequent. I don't however recommend you keep it at that value. Thanks, we may try that to see what effects it might have. Any pointers greatly appreaciated! Tom ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
