-------- Original Message --------
Subject: Re: [zfs-discuss] ZSF Solaris
Date: Wed, 01 Oct 2008 07:21:56 +0200
From: Jens Elkner <[EMAIL PROTECTED]>
To: zfs-discuss@opensolaris.org
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
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%
admin.graf /var/tmp > rm xx
admin.graf /var/tmp > time sh -c 'mkfile 2g xx ; sync'
0.05u 9.92s 0:31.75 31.4%
admin.graf /var/tmp > time sh -c 'mkfile 2g xx ; sync'
0.05u 305.15s 5:28.67 92.8%
admin.graf /var/tmp > time dd if=/dev/zero of=xx bs=1k count=2048
2048+0 records in
2048+0 records out
0.00u 298.40s 4:58.46 99.9%
admin.graf /var/tmp > time sh -c 'mkfile 2g xx ; sync'
0.05u 394.06s 6:52.79 95.4%
SunOS kaiser 5.10 Generic_137111-07 sun4u sparc SUNW,Sun-Fire-V440 (S10, U5)
=============================================================================
admin.kaiser /var/tmp > time mkfile 1g xx
0.14u 5.24s 0:26.72 20.1%
admin.kaiser /var/tmp > time mkfile 1g xx
0.13u 64.23s 1:25.67 75.1%
admin.kaiser /var/tmp > time mkfile 1g xx
0.13u 68.36s 1:30.12 75.9%
admin.kaiser /var/tmp > rm xx
admin.kaiser /var/tmp > time mkfile 1g xx
0.14u 5.79s 0:29.93 19.8%
admin.kaiser /var/tmp > time mkfile 1g xx
0.13u 66.37s 1:28.06 75.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%
SunOS dax 5.11 snv_79a i86pc i386 i86pc (U40, S11b79)
=============================================================================
elkner.dax /var/tmp > time mkfile 2g xx
0.05u 3.09s 0:43.09 7.2%
elkner.dax /var/tmp > time mkfile 2g xx
0.05u 4.95s 0:43.62 11.4%
The reason why the (implicit) truncation could be taking long might be
due to
*6723423 UFS slow following large file deletion with fix for 6513858
installed <http://monaco.sfbay/detail.jsf?cr=6723423>
*To overcome this problem for S10, the offending patch 127866-03 can be
removed.*
*Pramod*
*
Regards,
jel.
--
Otto-von-Guericke University http://www.cs.uni-magdeburg.de/
Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2
39106 Magdeburg, Germany Tel: +49 391 67 12768
_______________________________________________
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
