Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNrwL28044 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:53:58 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNrod28006 for ; Wed, 30 Jan 2002 15:53:50 -0800 Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0UMrbH13565; Thu, 31 Jan 2002 08:53:37 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by nut.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g0UMrb411071; Thu, 31 Jan 2002 08:53:37 +1000 (EST) Message-ID: <010601c1a9e0$f4210e20$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: "Stephen Lord" Cc: References: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> <3C57F97A.7000400@sgi.com> Subject: Re: How long should an xfs_freeze take? Date: Thu, 31 Jan 2002 08:51:50 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1557 Lines: 36 > How long freeze takes depends on how much data is dirty in the > filesystem, it should take a similar time to an unmount. However, > unless this was a very large and dirty filesystem this feels > like a long time - although it was all system time, > so something was going on. 6 hours is a long time for an unmount! The volume is ~70GB, and had no activity on it before I tried to create the snapshots - the machine had just been rebooted before some attempts. > The spot you kept seeing on the stack does not make much sense, vn_count is > basically an atomic_read. It just seems that's the place I've hit the break key the most. A closer examination of my console log suggests it isn't stuck in vn_count, there are a few occurances of it being somewhere else in xfs_iflush_all - so maybe it's got itself tangled in a loop for a few hours? 0xe95c3b88 0xc01a1a63 xfs_iflush_all+0xc3 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) 0xe95c3b88 0xc01a1ab9 xfs_iflush_all+0x119 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) 0xe95c3b88 0xc01a1ac3 xfs_iflush_all+0x123 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) > How repeatable is this? The problem was persistent across reboots - I rebooted to install a different LVM version at some stage (move to 1.0.2, from 1.0.1), and it occurred five times in a row after that. I just rebooted now to say that it still happens - but, alas - it doesn't want to any more. I'll try again at some random times throughout the day. Chris