From: Wang Shilong <wangshilong1991@gmail.com>
To: Jim Salter <jim@jrs-s.net>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs send: page allocation failure
Date: Tue, 14 Jan 2014 00:09:00 +0800 [thread overview]
Message-ID: <6D735AF4-6D5A-400F-9CE5-DFFCDBE6E0C3@gmail.com> (raw)
In-Reply-To: <52D40D99.8010301@jrs-s.net>
> It's a pretty new kernel - 3.13.0-031300rc7-generic.
>
> Sorry if I'm misunderstanding something, but... how can I send with -p
> if the parent snapshot doesn't already exist on the target?
Obviously, you can not…
Sorry, i was just thinking you use all the operations in one machine just like me ^_^
>
> What I'm doing is btrfs send /.snapshots/name-of-snapshot | ssh
> othermachine btrfs receive /.snapshots. If the parent specified in -p
> doesn't exist on othermachine, won't the receive operation fail?
>
> On 01/13/2014 10:44 AM, Wang Shilong wrote:
>> Just double check, what is your kernel version to trigger this problem…
>> I suppose this should be an older kernel? If yes, can you have a try at the latest
>> upstream kernel and see if problem still exist?
>>
>> Thanks,
>> Wang
>>
>>> 在 2014-1-13，下午11:20，Jim Salter <jim@jrs-s.net> 写道：
>>>
>>>> Er... I can't use incremental send if I can't get one full send to go through first. =)
>>> sory, i mean one approach is use '-p' option, you can use:
>>>
>>> # btrfs sub create subv
>>> # btrfs sub snapshot -r subv snap
>>> # btrfs sub snapshot -r sub snap1
>>> # btrfs send snap -p snap1 -f 1
>>> # btrfs receive -f 1 backup
>>> # btrfs sub delete snap1 -<-- now you can delete snap1 safely
>>>
>>> The above approach is much faster, i think you can try it!
>>>
>>> Thanks,
>>> Wang
>>>> I'm hoping the problem will go away for long enough to get a full send completed once I reboot the box, but I can't do that until (much) later in the day.
>>>>
>>>> On 01/13/2014 10:17 AM, Wang Shilong wrote:
>>>>> Hello,
>>>>>
>>>>> I took a careful think about your problems below, i think this is because btrfs *ulist* implement use
>>>>> krealloc which might cause memory allocation fails especial you use full send.
>>>>>
>>>>> Before we kicked off now stupid *ulist* implements, i think you can use incremental send to solve
>>>>> this issue.
>>>>>
>>>>> Thanks,
>>>>> Wang
>>>>>
>>>>>> Hi list -
>>>>>>
>>>>>> Getting sporadic page allocation failures in btrfs send. This happened once several weeks ago but was fine after a reboot; yesterday I did not reboot, but had the failure back-to-back trying to send two different snapshots. These are full sends, not incremental, of a bit over 600G of data. Test machine has 32G of RAM, with 21G of it free (not including cache):
>>>>>>
>>>>>> root@gwa-virt1:/data/images/.snapshots# free -m
>>>>>> total used free shared buffers cached
>>>>>> Mem: 32159 31789 369 0 0 21276
>>>>>> -/+ buffers/cache: 10513 21646
>>>>>> Swap: 0 0 0
>>>>>>
>>>>>> In both cases (all three, really) the btrfs send failed a bit more than half of the way through the send (somewhere around the 380GB mark).
>>>>>>
>>>>>> Kern log snippets follow:
>>>>>>
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627611] btrfs: page allocation failure: order:6, mode:0x104050
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627622] CPU: 6 PID: 9642 Comm: btrfs Not tainted 3.13.0-031300rc7-generic #201401041835
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627773] [<ffffffffa0142214>] ? btrfs_get_token_64+0x64/0xf0 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627818] [<ffffffffa01876dd>] ? ulist_add_merge+0xcd/0x270 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627860] [<ffffffffa01876dd>] ulist_add_merge+0xcd/0x270 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627894] [<ffffffffa018615c>] find_parent_nodes+0x50c/0x6f0 [btrf ]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627930] [<ffffffffa018e550>] ? compare_refs.isra.23+0x130/0x130 btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.627965] [<ffffffffa0187019>] iterate_extent_inodes+0xf9/0x270 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628003] [<ffffffffa014b7a5>] ? free_extent_buffer+0x35/0x40 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628037] [<ffffffffa018dc9d>] find_extent_clone.isra.26+0x26d/0x340 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628072] [<ffffffffa0191207>] process_extent+0xd7/0x180 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628107] [<ffffffffa01918ff>] changed_cb+0xdf/0x170 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628141] [<ffffffffa0191ad2>] full_send_tree+0x142/0x280 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628174] [<ffffffffa0191ccc>] ? send_subvol_begin+0xbc/0x2b0 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628209] [<ffffffffa0191fa0>] send_subvol+0xe0/0xf0 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628244] [<ffffffffa01922f1>] btrfs_ioctl_send+0x341/0x520 [btrfs]
>>>>>> Jan 12 14:05:36 gwa-virt1 kernel: [535523.628279] [<ffffffffa01606d3>] btrfs_ioctl+0x953/0xac0 [btrfs]
>>>>>>
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016512] btrfs: page allocation failure: order:5, mode:0x104050
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016518] CPU: 4 PID: 18689 Comm: btrfs Not tainted 3.13.0-031300rc7-generic #201401041835
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016597] [<ffffffffa0142214>] ? btrfs_get_token_64+0x64/0xf0 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016617] [<ffffffffa01876dd>] ? ulist_add_merge+0xcd/0x270 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016637] [<ffffffffa01876dd>] ulist_add_merge+0xcd/0x270 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016653] [<ffffffffa018615c>] find_parent_nodes+0x50c/0x6f0 [btrf ]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016669] [<ffffffffa018e550>] ? compare_refs.isra.23+0x130/0x130 btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016684] [<ffffffffa0187019>] iterate_extent_inodes+0xf9/0x270 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016700] [<ffffffffa014b7a5>] ? free_extent_buffer+0x35/0x40 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016716] [<ffffffffa018dc9d>] find_extent_clone.isra.26+0x26d/0x340 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016732] [<ffffffffa0191207>] process_extent+0xd7/0x180 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016747] [<ffffffffa01918ff>] changed_cb+0xdf/0x170 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016763] [<ffffffffa0191ad2>] full_send_tree+0x142/0x280 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016778] [<ffffffffa0191ccc>] ? send_subvol_begin+0xbc/0x2b0 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016794] [<ffffffffa0191fa0>] send_subvol+0xe0/0xf0 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016810] [<ffffffffa01922f1>] btrfs_ioctl_send+0x341/0x520 [btrfs]
>>>>>> Jan 12 21:34:00 gwa-virt1 kernel: [562448.016826] [<ffffffffa01606d3>] btrfs_ioctl+0x953/0xac0 [btrfs]
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-01-13 16:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 12:58 btrfs send: page allocation failure Jim Salter
2014-01-13 15:17 ` Wang Shilong
2014-01-13 15:20 ` Jim Salter
2014-01-13 15:29 ` Wang Shilong
2014-01-13 15:44 ` Wang Shilong
2014-01-13 16:00 ` Jim Salter
2014-01-13 16:09 ` Wang Shilong [this message]
2014-01-13 16:01 ` Jim Salter
2014-01-13 18:23 ` David Sterba
2014-01-13 18:36 ` Josef Bacik
2014-01-13 18:37 ` Jim Salter
2014-01-13 18:56 ` David Sterba
2014-01-13 19:03 ` Jim Salter
2014-01-14 13:13 ` David Sterba
2014-01-14 14:58 ` Jim Salter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6D735AF4-6D5A-400F-9CE5-DFFCDBE6E0C3@gmail.com \
--to=wangshilong1991@gmail.com \
--cc=jim@jrs-s.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox