From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761972AbYEFNyO (ORCPT ); Tue, 6 May 2008 09:54:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757657AbYEFNx7 (ORCPT ); Tue, 6 May 2008 09:53:59 -0400 Received: from sandeen.net ([209.173.210.139]:31757 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757607AbYEFNx6 (ORCPT ); Tue, 6 May 2008 09:53:58 -0400 Message-ID: <482062F5.9010402@sandeen.net> Date: Tue, 06 May 2008 08:53:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Marco Berizzi CC: David Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS shutdown in xfs_iunlink_remove() (was Re: 2.6.25: swapper: page allocation failure. order:3, mode:0x4020) References: <20080505231754.GL155679365@sgi.com> <20080506085632.GT155679365@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Marco Berizzi wrote: > David Chinner wrote: > >> Hmmmmm - interesting. Both the reports of this problem are from >> machines running as squid proxies. Are you using AUFS for the cache? > > no, I'm using cache_dir ufs with cache_replacement_policy heap LFUDA > >> You've run repair, there's not much I can look at now. >> >> As a suggestion, when the cache gets close to full next time, can >> you take a metadump of the filesystem (obfuscates names and contains >> no data) and then trigger the cache cleanup function? If the >> filesystem falls over, I'd be very interested in getting a copy of >> hte metadump image and trying to reproduce the problem locally. >> (BTW, you'll need a newer xfsprogs to get xfs_metadump). > > could you please tell me the exact command to run > when this happen again? xfs_metadump /dev/hda8 /path/to/the/image/you/are/creating will make a metadata image of the on device hda8 and store it in the filename given on the 2nd argument. The idea is to catch the metadata state shortly before the cache cleanup triggers; this might lead to a reproducible testcase (sgi guys could then restore the metadata image, simulate the cache cleanup, see what happens). Thanks, -Eric >> Still, thank you for the information > > no problem: 2.6.25 is a bit unlucky for me :-(( > > > >