[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <482062F5.9010402@sandeen.net>
Date: Tue, 06 May 2008 08:53:57 -0500
From: Eric Sandeen <sandeen@...deen.net>
To: Marco Berizzi <pupilla@...mail.com>
CC: David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
xfs@....sgi.com
Subject: Re: XFS shutdown in xfs_iunlink_remove() (was Re: 2.6.25: swapper:
page allocation failure. order:3, mode:0x4020)
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 :-((
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists