On 25. juli 2014 11:28, Liu Bo wrote:
Hi Torbjørn,
On Fri, Jul 25, 2014 at 06:51:44AM +0200, Torbjørn wrote:
On 07/24/2014 04:58 PM, Chris Mason wrote:
<snip>
Liu Bo has a promising patch:
https://patchwork.kernel.org/patch/4618421/
Please give it a shot. There's a second deadlock reading the free space
cache, I'm still working on that one too.
-chris
I (as expected, my hang was with free space cache) still get hangs
with this applied on top of 3.16-rc6.
Looking forward to the free space cache patch.
I have not been able to trigger the same hang as I had with 3.15 on
any of the 3.16-rc6 kernels so far.
Seems that you can run into the hang quite stably, I have a stupid debugging
patch here with adding a WARN_ON() to __load_free_space_inode(), would you
please give it a shot and show us the output of dmesg?
(This may make 'dmesg' a mess, but it will show who the hell holds the free
space inode's page just at the time before hang)
thanks,
-liubo
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 2b0a627..e364888 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -350,6 +350,8 @@ static int io_ctl_prepare_pages(struct io_ctl *io_ctl,
struct inode *inode,
gfp_t mask = btrfs_alloc_write_mask(inode->i_mapping);
int i;
+ WARN_ON(1);
+
for (i = 0; i < io_ctl->num_pages; i++) {
page = find_or_create_page(inode->i_mapping, i, mask);
if (!page) {
That patch did not apply cleanly on top of current linus master.
Not sure what branch you are at, so I added that WARN_ON(1); manually in
free-space-cache.c.
I reverted all the other patches before manually applying this one.
If you need me to test from some other branch or with some other patch
included, please let me know.
I'm doing a build now. Will run my rsync job and report back.
Thanks.
--
Torbjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
