[Resending in plain text, apologies.]
Hi Chandan, Josef, Chris,
I am not sure I understand the fix to the problem.
It may happen that when updating the device tree, we need to allocate a new
chunk via do_chunk_alloc (while we are holding the device tree root node
locked). This is a legitimate
On Sunday 13 Dec 2015 12:18:55 Alex Lyakas wrote:
> [Resending in plain text, apologies.]
>
> Hi Chandan, Josef, Chris,
>
> I am not sure I understand the fix to the problem.
>
> It may happen that when updating the device tree, we need to allocate a new
> chunk via do_chunk_alloc (while we are
On 11/02/2015 03:29 AM, Chandan Rajendra wrote:
When executing generic/001 in a loop on a ppc64 machine (with both sectorsize
and nodesize set to 64k), the following call trace is observed,
WARNING: at /root/repos/linux/fs/btrfs/locking.c:253
Modules linked in:
CPU: 2 PID: 8353 Comm: umount Not
When executing generic/001 in a loop on a ppc64 machine (with both sectorsize
and nodesize set to 64k), the following call trace is observed,
WARNING: at /root/repos/linux/fs/btrfs/locking.c:253
Modules linked in:
CPU: 2 PID: 8353 Comm: umount Not tainted 4.3.0-rc5-13676-ga5e681d #54
task:
On Mon, Nov 02, 2015 at 01:59:46PM +0530, Chandan Rajendra wrote:
> When executing generic/001 in a loop on a ppc64 machine (with both sectorsize
> and nodesize set to 64k), the following call trace is observed,
Thanks Chandan, I hit this same trace on x86-64 with 16K nodes.
-chris
--
To
