Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Aug 2002 14:34:15 -0700 (PDT) Received: from imf06bis.bellsouth.net (mail006.mail.bellsouth.net [205.152.58.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7ULYDtG028693 for ; Fri, 30 Aug 2002 14:34:13 -0700 Received: from TAZ2 ([66.156.1.201]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020830213927.JHR2736.imf06bis.bellsouth.net@TAZ2>; Fri, 30 Aug 2002 17:39:27 -0400 Date: Fri, 30 Aug 2002 17:36:29 -0400 From: Greg Freemyer Subject: re[4]: snapshot regression test try 2 To: Steve Lord cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-type: text/plain Message-Id: <20020830213927.JHR2736.imf06bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g7ULYDtG028695 X-archive-position: 175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Steve, I have compiled the CVS kernel from xfs, and have tried my snapshot script on it. It has successfully done 20 iterations. (this is a first for me.) Not only did it succeed at this, but the time to perform an iteration dropped drastically from using my prior kernel. i.e. It typically took a couple of minutes per iteration to take the snapshot/mount it/unmount it/delete it. Now it is taking around 10 seconds. I have changed the iteration counter to 10,000 and I'm going to let it run over the long weekend. Hopefully we will have a success with this pure xfs cvs kernel. Greg >> On Fri, 2002-08-30 at 10:59, Greg Freemyer wrote: >> > >> > >> > >> I have subsequently been chasing oopses from running freeze/thaw >> > >> on a filesystem under heavy load, but that is a different problem >> > >> than you saw I think. >> > >> > Steve, >> > >> > If you can characterize the load, then you can simply replace my dd loop >> with one that creates the load you need. >> > >> > Maybe that will help. >> The load is dbench 32, running a freeze/thaw operation every 10 seconds. >> No LVM needed here. This appears to expose a hole in the inode create >> and teardown logic. >> Steve >> -- >> Steve Lord voice: +1-651-683-3511 >> Principal Engineer, Filesystem Software email: lord@sgi.com Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Grou www.NorcrossGroup.com