From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp1040.oracle.com ([156.151.31.81]:36467 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754154AbaDKJ2h (ORCPT ); Fri, 11 Apr 2014 05:28:37 -0400 Date: Fri, 11 Apr 2014 17:28:28 +0800 From: Liu Bo To: Chip Turner Cc: linux-btrfs@vger.kernel.org Subject: Re: Filesystem unable to recover from ENOSPC Message-ID: <20140411092827.GD26503@localhost.localdomain> Reply-To: bo.li.liu@oracle.com References: <20140410203439.GB20307@carfax.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Thu, Apr 10, 2014 at 11:10:33PM -0700, Chip Turner wrote: > Thank you for the extremely detailed and helpful reply. I now > understand what was happening. To me, when I read "total=" I guess I > thought that was capacity rather than allocated (but now "holey") > chunks. I agree that perhaps adjusting the phrasing of the output of > df and show would be helpful in making this clearer (or perhaps some > adjustment to the wiki; maybe I will do that). > > I assume metadata is where filesystem information (directory entries, > inodes, etc) are stored and not being able to delete was because there > wasn't room in the metadata chunks, and no room to allocate more > metadata chunks? Or are those also data chunks and it was purely > about data chunks? Yes and no. Deleting metadata also needs metadata, and metadata chunk and data chunk are different ones. > > Does defrag do similar reallocation to balance such that it would help > combat this behavior? I'm afraid it won't, since you have that many hardlinks, defrag may not help on reducing metadata. thanks, -liubo