From: Josef Bacik <jbacik@fb.com>
To: Filipe Manana <fdmanana@suse.com>, fstests@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] fstests: test btrfs send after swapping directory names differently
Date: Fri, 24 Apr 2015 14:11:03 -0400 [thread overview]
Message-ID: <553A8737.8030600@fb.com> (raw)
In-Reply-To: <1428591389-3668-1-git-send-email-fdmanana@suse.com>
On 04/09/2015 10:56 AM, Filipe Manana wrote:
> Test btrfs incremental send after renaming and moving directories around in a
> way that ends up making a directory have different dentries with the same name
> but pointing to different inodes in the parent and send snapshots, and also
> inverting the ancestor-descendent relationship between one of those inodes and
> some other inode.
>
> Cases like this made an incremental send enter an infinite lopp when building
> path strings, leading to -ENOMEM errors when the path string reached a length
> of PATH_MAX.
> This issue was fixed by the following linux kernel btrfs patch:
>
> Btrfs: incremental send, check if orphanized dir inode needs delayed rename
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Verified it passed with the patches applied and failed without them.
Test looks straightforward and good to me, you can add
Reviewed-by: Josef Bacik <jbacik@fb.com>
Thanks,
Josef
WARNING: multiple messages have this Message-ID (diff)
From: Josef Bacik <jbacik@fb.com>
To: Filipe Manana <fdmanana@suse.com>, <fstests@vger.kernel.org>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] fstests: test btrfs send after swapping directory names differently
Date: Fri, 24 Apr 2015 14:11:03 -0400 [thread overview]
Message-ID: <553A8737.8030600@fb.com> (raw)
In-Reply-To: <1428591389-3668-1-git-send-email-fdmanana@suse.com>
On 04/09/2015 10:56 AM, Filipe Manana wrote:
> Test btrfs incremental send after renaming and moving directories around in a
> way that ends up making a directory have different dentries with the same name
> but pointing to different inodes in the parent and send snapshots, and also
> inverting the ancestor-descendent relationship between one of those inodes and
> some other inode.
>
> Cases like this made an incremental send enter an infinite lopp when building
> path strings, leading to -ENOMEM errors when the path string reached a length
> of PATH_MAX.
> This issue was fixed by the following linux kernel btrfs patch:
>
> Btrfs: incremental send, check if orphanized dir inode needs delayed rename
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Verified it passed with the patches applied and failed without them.
Test looks straightforward and good to me, you can add
Reviewed-by: Josef Bacik <jbacik@fb.com>
Thanks,
Josef
next prev parent reply other threads:[~2015-04-24 18:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 14:56 [PATCH] fstests: test btrfs send after swapping directory names differently Filipe Manana
2015-04-24 18:11 ` Josef Bacik [this message]
2015-04-24 18:11 ` Josef Bacik
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=553A8737.8030600@fb.com \
--to=jbacik@fb.com \
--cc=fdmanana@suse.com \
--cc=fstests@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.