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 <cwillu@xxxxxxxxxx>:
> On Fri, Mar 22, 2013 at 12:13 AM, Roman Mamedov <rm@xxxxxxxxxx> wrote:
>> On Thu, 21 Mar 2013 20:42:28 +0100
>> Stefan Priebe <s.priebe@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
