On 3/19/14, 8:20 PM, "Marc MERLIN" <marc@xxxxxxxxxxx> wrote:
>On Thu, Mar 20, 2014 at 12:13:36AM +0000, Chris Mason wrote:
>> >Should I double it?
>> >
>> >For now, I have the copy running again, and it's been going for 8 hours
>> >without failure on the old kernel but of course that doesn't mean my
>>2TB
>> >copy will complete without hitting the bug again.
>>
>> Sorry, I misspoke, you should bump /proc/sys/vm/min_free_kbytes.
>>Honestly
>> though, it¹s just a bug in the mvs driver. Atomic 8K allocations are
>> doomed to fail eventually.
>
>Gotcha
>polgara:/mnt/btrfs_backupcopy# cat /proc/sys/vm/min_free_kbytes
>45056
>polgara:/mnt/btrfs_backupcopy# echo 100000 > /proc/sys/vm/min_free_kbytes
>polgara:/mnt/btrfs_backupcopy# cat /proc/sys/vm/min_free_kbytes
>100000
>polgara:/mnt/btrfs_backupcopy#
>
>> The driver should either busy loop until the allocation completes
>>(really
>> not a great choice), gracefully deal with the failure (looks tricky), or
>> preallocate the space (like the rest of the block layer).
>
>Gotcha. I'll report this to the folks maintaining the marvel driver.
>
>So just to make sure I got you right, although the page allocation failure
>was shown in btrfs, it's really the underlying marvel driver at fault
>here,
>and there isn't really anything to change on the btrfs side, correct?
The process is a btrfs worker, and the IO was started by btrfs, but the
allocation failure is all inside the mvs driver. There’s even the printk
in there from mvs about the allocation failing.
The only reason it’s btrfs instead of a regular process is because for
raid5/6 the rmw is farmed out to helper threads.
-chris
ÿ淸º{.nÇ+돴윯돪†+%듚ÿ깁負¥Šwÿº{.nÇ+돴¥Š{깰»k~穹왲^n‡r⊆¦zË곷h솳鈺Ú&｛àz요z받쀺+€Ê+zf＂·hš닱~넮녬iÿÿï곴ÿ묎çz_溫æj:+v돣þ)山øm
