Jens Elkner wrote:
On Mon, Oct 06, 2008 at 08:01:39PM +0530, Pramod Batni wrote:
On Tue, Sep 30, 2008 at 09:44:21PM -0500, Al Hopper wrote:
This behavior is common to tmpfs, UFS and I tested it on early ZFS
releases. I have no idea why - I have not made the time to figure it
out. What I have observed is that all operations on your (victim)
test directory will max out (100% utilization) one CPU or one CPU core
- and all directory operations become single-threaded and limited by
the performance of one CPU (or core).
And sometimes its just a little bug: E.g. with a recent version of Solaris
(i.e. >= snv_95 || >= S10U5) on UFS:
SunOS graf 5.10 Generic_137112-07 i86pc i386 i86pc (X4600, S10U5)
=============================================================================
admin.graf /var/tmp > time sh -c 'mkfile 2g xx ; sync'
0.05u 9.78s 0:29.42 33.4%
admin.graf /var/tmp > time sh -c 'mkfile 2g xx ; sync'
0.05u 293.37s 5:13.67 93.5%
SunOS q 5.11 snv_98 i86pc i386 i86pc (U40, S11b98)
=============================================================================
elkner.q /var/tmp > time mkfile 2g xx
0.05u 3.63s 0:42.91 8.5%
elkner.q /var/tmp > time mkfile 2g xx
0.04u 315.15s 5:54.12 89.0%
The reason why the (implicit) truncation could be taking long might be due
to
6723423 [6]UFS slow following large file deletion with fix for 6513858
installed
To overcome this problem for S10, the offending patch 127866-03 can be
removed.
Yes - removing 127867-05 (x86, i.e. going back to 127867-02) resolved
the problem. On sparc removing 127866-05 brought me back to 127866-01
which didn't seem to solve the problem (maybe because didn't init 6
before). However installing 127866-02 and init 6 fixed it on sparc as well.
Any hints, in which snv release it is fixed?
It is not yet fixed in snv. A fix is being developed, not sure which
build it would be available in.
Pramod
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
