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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
