From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 90EAD7CA1 for ; Mon, 11 Jul 2016 17:54:05 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 02B0AAC001 for ; Mon, 11 Jul 2016 15:54:01 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id WBUwrFxUbtRs7Els for ; Mon, 11 Jul 2016 15:53:59 -0700 (PDT) Date: Tue, 12 Jul 2016 08:53:57 +1000 From: Dave Chinner Subject: Re: [QUESTION] about the freelist allocator in XFS Message-ID: <20160711225357.GG1922@dastard> References: <20160707222829.GG12670@dastard> <20160710232217.GB1922@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: Kaho Ng Cc: xfs@oss.sgi.com On Mon, Jul 11, 2016 at 03:06:03PM +0800, Kaho Ng wrote: > Just wonders why we prefer failing the request of refilling freelist > with XFS_WANT_CORRUPTED_RETURN(mp, i == 1) in some rare case, rather > than returning NULLAGBLOCK and allowing the loop in > xfs_alloc_ag_vextent_size() to try xfs_alloc_ag_vextent_small()... Have a look at where xfs_alloc_ag_vextent_small() gets the blocks it returns to the caller if the btree cursor doesn't point to a btree record we can use. i.e. you can't refill the free list from xfs_alloc_ag_vextent_small() because it allocates blocks from ... > In > such corner case there will always be a lot of small extents at the > front of the by-count tree, and any truncation changes to the first > entry in the tree will not result in tree splits and triggering > assertion failure. If there are records we can use, then we'll allocate them from the btree. Failure to allocate from the btree indicates something is inconsistent, there's a bug in the code or we've got corruption occuring. A corruption shutdown is the only safe course of action when we find something confusing like this - if we guess wrong them we'll only make the bad state/corruption worse. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs