> -------- Original Message -------- > Subject: Re: [zfs-discuss] ZSF Solaris > Date: Wed, 01 Oct 2008 07:21:56 +0200 > From: Jens Elkner <jel+zfs at cs.uni-magdeburg.de> > To: zfs-discuss at opensolaris.org > References: <25133637.1051222775436584.JavaMail.Twebapp at sf-app1> > <89243EBA-3E2C-4AAA-8EB2-A1F9984C6B08 at telegraphics.com.au> > <48E2B6A1.6010409 at Sun.COM> > <4cb4ba740809301944m272cdb3codddd9fb2519d7ccd at mail.gmail.com> > > > > 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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081006/075ea738/attachment.html>
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? Thanx a lot, 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
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081007/b7158a1a/attachment.html>
On Tue, Oct 07, 2008 at 11:35:47AM +0530, Pramod Batni wrote:> 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. > > It is not yet fixed in snv. A fix is being developed, not sure which > build it would be available in.OK - thanx for your answer. Since the fixes in 03-05 seem to be important, I''ll try to initiate an escalation of the case - does it help to get it in a little bit earlier? 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
Jens Elkner wrote:> On Tue, Oct 07, 2008 at 11:35:47AM +0530, Pramod Batni wrote: > > >> 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. >> >> It is not yet fixed in snv. A fix is being developed, not sure which >> build it would be available in. >> > > OK - thanx for your answer. Since the fixes in 03-05 seem to be > important, I''ll try to initiate an escalation of the case - does it help > to get it in a little bit earlier? >There are a couple of escalations already on 6723423. In case you want an IDR [an interim relief] you can initiate an escalation. Pramod> Regards, > jel. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081009/bc70da00/attachment.html>