Bcache deadlocks on 'git clone' with backing device over NFS

Bcache deadlocks on 'git clone' with backing device over NFS

[Jean-Tiare LE BIGOT]

Sorry if you got this message twice. I had no idea where to submit a bug 
report.

When using a loopback device over NFS as backing device (like for a VM), 
Bcache appears to dead-lock. But it works flawlessly when backing device 
is an RBD image.

It appears to occur under heavy I/O load. For example, when cloning 
kernel's git repository:

# /dev/sdc --> 80G local SSD
# /dev/loop0 --> blob over nfs
#            --> (works well with RBD for instance)
$ make-bcache -C /dev/loop0 -B /dev/sdc
$ mkfs.ext4 /dev/bcache0
$ mount /dev/bcache0 /mnt/bcache-test
$ cd /mnt/bcache-test
$ time git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Cloning into 'linux'...
remote: Counting objects: 3408218, done.
remote: Compressing objects: 100% (518044/518044), done.
remote: Total 3408218 (delta 2869505), reused 3399526 (delta 2861017)
Receiving objects: 100% (3408218/3408218), 713.99 MiB | 18.16 MiB/s, done.
Resolving deltas: 100% (2869505/2869505), done.
<git process in 'D' state>

Obviously any further I/O on the device locks too so that 'sync' and 
hence clean reboot locks as well.

Here GIT kernel-side stack-trace in this case:

$ uname -a
Linux webp310.cluster016.ha.ovh.net 3.10.26-mutu-ipv6-64-paas+ #9 SMP
Fri Jan 10 11:16:23 CET 2014 x86_64 GNU/Linux

$ echo t > /proc/sysrq-trigger

git             D 0000000000000000     0 10521  10519 0x00000000
  ffff8805fb6b9c98 0000000000000082 0000000000011b00 ffff8805fc8c6f00
  0000000000011b00 ffff8805fb6b9fd8 ffff8805fb6b8010 0000000000011b00
  ffff8805fb6b9fd8 0000000000011b00 ffff8805fc8c6f00 ffff8805fdef14d0
Call Trace:
  [<ffffffff8112f4c0>] ? __lock_page+0x70/0x70
  [<ffffffff81cc8ec4>] schedule+0x24/0x70
  [<ffffffff81cc8f97>] io_schedule+0x87/0xd0
  [<ffffffff8112f4c9>] sleep_on_page+0x9/0x10
  [<ffffffff81cc74e7>] __wait_on_bit+0x57/0x80
  [<ffffffff8112efec>] ? find_get_pages_tag+0xcc/0x180
  [<ffffffff8112f6de>] wait_on_page_bit+0x6e/0x80
  [<ffffffff810e1db0>] ? autoremove_wake_function+0x40/0x40
  [<ffffffff8113afb0>] ? pagevec_lookup_tag+0x20/0x30
  [<ffffffff8112fb6f>] filemap_fdatawait_range+0x10f/0x1b0
  [<ffffffff8112fd30>] filemap_write_and_wait_range+0x90/0xa0
  [<ffffffff81262bf0>] ext4_sync_file+0x50/0x290
  [<ffffffff811a9193>] vfs_fsync_range+0x23/0x30
  [<ffffffff811a91b7>] vfs_fsync+0x17/0x20
  [<ffffffff811a93ec>] do_fsync+0x3c/0x60
  [<ffffffff811a943b>] SyS_fsync+0xb/0x10
  [<ffffffff81ccae12>] system_call_fastpath+0x16/0x1b


Is it a known bug ? How may I avoid dead-locking ?

-- 
Jean-Tiare, team Mutu