From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:60153 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932204Ab3FGXOk (ORCPT ); Fri, 7 Jun 2013 19:14:40 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ul5rc-0000xT-BT for linux-btrfs@vger.kernel.org; Sat, 08 Jun 2013 01:14:32 +0200 Received: from cpc21-stap10-2-0-cust974.12-2.cable.virginmedia.com ([86.0.163.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Jun 2013 01:14:32 +0200 Received: from m_btrfs by cpc21-stap10-2-0-cust974.12-2.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Jun 2013 01:14:32 +0200 To: linux-btrfs@vger.kernel.org From: Martin Subject: Re: btrfs raid1 on 16TB goes read-only after "btrfs: block rsv returned -28" Date: Sat, 08 Jun 2013 00:14:09 +0100 Message-ID: References: <20130605150549.GP20133@carfax.org.uk> <20130605154329.GQ20133@carfax.org.uk> <20130605162443.GE18160@twin.jikos.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 05/06/13 22:12, Martin wrote: > On 05/06/13 17:24, David Sterba wrote: >> On Wed, Jun 05, 2013 at 04:43:29PM +0100, Hugo Mills wrote: >>> OK, so you've got plenty of space to allocate. There were some >>> issues in this area (block reserves and ENOSPC, and I think >>> specifically addressing the issue of ENOSPC when there's space >>> available to allocate) that were fixed between 3.8 and 3.9 (and >>> probably some between 3.9 and 3.10-rc as well), so upgrading your >>> kernel _may_ help here. >> >> This is supposed to be fixed by >> https://patchwork-mail2.kernel.org/patch/2558911/ >> >> that went ti 3.10-rc with some followup patches, so it might not be >> enough as a standalone fix. >> >> Unless you really need 'inode_cache', remove it from the mount options. > > Thanks for that. Remounting without the inode_cache option looks to be > allowing rsync to continue. (No sync loop needed.) rsync is still running ok but the data copying is awfully slow... The copy across is going to take many days at this rate :-( > For a 16TB raid1 on kernel 3.8.13, any good mount options to try? > > For that size of storage and with many hard links, is there any > advantage formatting with leaf/node size greater than the default 4kBytes? Any hints/tips? ;-) Regards, Martin