From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DFAA67F7D for ; Tue, 8 Oct 2013 15:23:45 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id BA1D2304039 for ; Tue, 8 Oct 2013 13:23:45 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id 1HfGfKXBh6jnQM0g for ; Tue, 08 Oct 2013 13:23:44 -0700 (PDT) Date: Wed, 9 Oct 2013 07:23:42 +1100 From: Dave Chinner Subject: Re: xfs_repair segfault Message-ID: <20131008202342.GA4446@dastard> References: <20131001201909.GR12541@dastard> <20131002104253.GT12541@dastard> <20131004214353.GK4446@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Viet Nguyen Cc: xfs@oss.sgi.com On Mon, Oct 07, 2013 at 01:09:09PM -0700, Viet Nguyen wrote: > Thanks. That seemed to fix that bug. > > Now I'm getting a lot of this: > xfs_da_do_buf(2): XFS_CORRUPTION_ERROR Right, that's blocks that are being detected as corrupt when they are read. You can ignore that for now. > fatal error -- can't read block 8388608 for directory inode 8628218 That's a corrupted block list of some kind - it should junk the inode. > Then xfs_repair exits. I'm not sure why that happens. Is it exiting cleanly or crashing? Can you take a metadump of the filesystem and provide it for someone to debug the problems it causes repair? > What I've been doing is what I saw in the FAQ where I would use xfs_db and > write core.mode 0 for these inodes. But there are just so many of them. And > is that even the right thing to do? That marks the inode as "free" which effectively junks it and then xfs_repair will free all it's extents next time it is run. Basically you are removing the files from the filesystem and making them unrecoverable. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs