From: Jean-Tiare LE BIGOT <jean-tiare.le-bigot@ovh.net>
To: linux-bcache@vger.kernel.org
Subject: Bcache deadlocks on 'git clone' with backing device over NFS
Date: Thu, 30 Jan 2014 10:16:19 +0100 [thread overview]
Message-ID: <52EA1863.1000601@ovh.net> (raw)
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
reply other threads:[~2014-01-30 9:22 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=52EA1863.1000601@ovh.net \
--to=jean-tiare.le-bigot@ovh.net \
--cc=linux-bcache@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.