On Tue, Apr 12, 2016 at 5:52 PM, Julian Taylor
wrote:
> smaller testcase that shows the immediate enospc after fallocate -> rm,
> though I don't know if it is really related to the full filesystem
> bugging out as the balance does work if you wait a few seconds after the
> balance.
> But this sequ
Julian Taylor posted on Tue, 12 Apr 2016 17:52:57 +0200 as excerpted:
> $ sudo btrfs fi balance start -dusage=0 .
> ERROR: error during balancing '.': No space left on device
Not much to add, but this one really surprises me and it may be related
to the new problem you're seeing.
I don't recall
On 12.04.2016 20:09, Henk Slager wrote:
> On Tue, Apr 12, 2016 at 5:52 PM, Julian Taylor
> wrote:
>> smaller testcase that shows the immediate enospc after fallocate -> rm,
>> though I don't know if it is really related to the full filesystem
>> bugging out as the balance does work if you wait a f
On Tue, Apr 12, 2016 at 5:52 PM, Julian Taylor
wrote:
> smaller testcase that shows the immediate enospc after fallocate -> rm,
> though I don't know if it is really related to the full filesystem
> bugging out as the balance does work if you wait a few seconds after the
> balance.
> But this sequ
smaller testcase that shows the immediate enospc after fallocate -> rm,
though I don't know if it is really related to the full filesystem
bugging out as the balance does work if you wait a few seconds after the
balance.
But this sequence of commands did work in 4.2.
$ sudo btrfs fi show /dev/map
hi,
I have a system with two filesystems which are both affected by the
notorious enospace bug when there is plenty of unallocated space
available. The system is a raid0 on two 900 GiB disks and an iscsi
single/dup 1.4TiB.
To deal with the problem I use a cronjob that uses fallocate to give me
an a
