Already tried with value 5 did not help ;-( and it also happens with plain cp copying a 15gb file and aborts at about 80%
Am 22.03.2013 um 07:24 schrieb cwillu <cwi...@cwillu.com>: > On Fri, Mar 22, 2013 at 12:13 AM, Roman Mamedov <r...@romanrm.ru> wrote: >> On Thu, 21 Mar 2013 20:42:28 +0100 >> Stefan Priebe <s.pri...@profihost.ag> wrote: >> >> I might be wrong here, but doesn't this >> >>> rsync: rename >>> "/mnt/.software/kernel/linux-3.9-rc3/drivers/infiniband/hw/amso1100/"" >>> -> >>> ".software/kernel/linux-3.9-rc3/drivers/infiniband/hw/amso1100/c2_ae.h": >> >> ...try to move a file from >> >> "/mnt/.software/" >> >> to >> >> ".software/" >> >> (relative to current dir)?? > > No; that's rsync giving the full path, and then the target path > relative to the command it was given. The filename itself > (".c2_ae.h.WEhLGP") is a semi-random filename rsync uses to write to > temporarily, so it can mv it over the original in an atomic fashion... > > Stefan: ...which means that the actual copy succeeded, which suggests > that this is more of a metadata enospc thing. > > You might try btrfs balance start -musage=5 (instead of -dusage), and > if that doesn't report any chunks balanced, try a high number until it > does. -- 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