From: Neuer User <auslands-kv@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: task sync:2450 blocked for more than 120 seconds.
Date: Thu, 01 May 2014 10:14:35 +0200 [thread overview]
Message-ID: <ljsvpb$cl6$1@ger.gmane.org> (raw)
In-Reply-To: <ljq5o6$f0d$1@ger.gmane.org>
It's probably best to copy al my data to another disk, then delete the
parttiion and make a new ext4 partition. btrfs is probably still too
experimental, I guess.
Am 30.04.2014 08:37, schrieb Neuer User:
> Hi
>
> I have a non-rootfs btrfs partition that I use for some work where I
> like to keep some snapshots. The partition is about 160GB big and has
> about 80-90 GB of data.
>
> I often see the following errors:
>
> Apr 29 20:41:24 DesktopMB kernel: [47030.195270] INFO: task sync:2450
> blocked for more than 120 seconds.
> Apr 29 20:41:24 DesktopMB kernel: [47030.195275] Tainted: GF
> O 3.14.1-031401-generic #201404141220
> Apr 29 20:41:24 DesktopMB kernel: [47030.195276] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 29 20:41:24 DesktopMB kernel: [47030.195277] sync D
> ffffffff818118e0 0 2450 29298 0x00000004
> Apr 29 20:41:24 DesktopMB kernel: [47030.195280] ffff8801261bbc68
> 0000000000000002 ffff8801261bbc18 ffff8801261bbfd8
> Apr 29 20:41:24 DesktopMB kernel: [47030.195282] 00000000000144c0
> 00000000000144c0 ffff88022341b1e0 ffff88012606cad0
> Apr 29 20:41:24 DesktopMB kernel: [47030.195284] ffff8801261bbc68
> ffff88022f3d4dc8 ffff88012606cad0 ffffffff8115f460
> Apr 29 20:41:24 DesktopMB kernel: [47030.195286] Call Trace:
> Apr 29 20:41:24 DesktopMB kernel: [47030.195292] [<ffffffff8115f460>] ?
> __lock_page+0x70/0x70
> Apr 29 20:41:24 DesktopMB kernel: [47030.195295] [<ffffffff817650e9>]
> schedule+0x29/0x70
> Apr 29 20:41:24 DesktopMB kernel: [47030.195297] [<ffffffff817651bf>]
> io_schedule+0x8f/0xd0
> Apr 29 20:41:24 DesktopMB kernel: [47030.195299] [<ffffffff8115f46e>]
> sleep_on_page+0xe/0x20
> Apr 29 20:41:24 DesktopMB kernel: [47030.195300] [<ffffffff81765882>]
> __wait_on_bit+0x62/0x90
> Apr 29 20:41:24 DesktopMB kernel: [47030.195302] [<ffffffff8115ff0b>] ?
> find_get_pages_tag+0xcb/0x170
> Apr 29 20:41:24 DesktopMB kernel: [47030.195304] [<ffffffff8115f5d0>]
> wait_on_page_bit+0x80/0x90
> Apr 29 20:41:24 DesktopMB kernel: [47030.195307] [<ffffffff810b51c0>] ?
> wake_atomic_t_function+0x40/0x40
> Apr 29 20:41:24 DesktopMB kernel: [47030.195309] [<ffffffff8115f6d4>]
> filemap_fdatawait_range+0xf4/0x180
> Apr 29 20:41:24 DesktopMB kernel: [47030.195312] [<ffffffff8108624a>] ?
> __queue_delayed_work+0xaa/0x1a0
> Apr 29 20:41:24 DesktopMB kernel: [47030.195314] [<ffffffff810867c5>] ?
> try_to_grab_pending+0x65/0x80
> Apr 29 20:41:24 DesktopMB kernel: [47030.195316] [<ffffffff8115f78b>]
> filemap_fdatawait+0x2b/0x30
> Apr 29 20:41:24 DesktopMB kernel: [47030.195319] [<ffffffff811fa6a5>]
> wait_sb_inodes+0xc5/0x120
> Apr 29 20:41:24 DesktopMB kernel: [47030.195321] [<ffffffff81202300>] ?
> fdatawrite_one_bdev+0x20/0x20
> Apr 29 20:41:24 DesktopMB kernel: [47030.195323] [<ffffffff811fa7a3>]
> sync_inodes_sb+0xa3/0xd0
> Apr 29 20:41:24 DesktopMB kernel: [47030.195325] [<ffffffff8120231d>]
> sync_inodes_one_sb+0x1d/0x30
> Apr 29 20:41:24 DesktopMB kernel: [47030.195328] [<ffffffff811d5711>]
> iterate_supers+0xf1/0x100
> Apr 29 20:41:24 DesktopMB kernel: [47030.195330] [<ffffffff81202485>]
> sys_sync+0x35/0x90
> Apr 29 20:41:24 DesktopMB kernel: [47030.195333] [<ffffffff8177247f>]
> tracesys+0xe1/0xe6
> Apr 29 20:43:24 DesktopMB kernel: [47150.168257] INFO: task sync:2450
> blocked for more than 120 seconds.
>
> In such a case I can only emergency remount and
> power of the system. Nothing else.
>
> I am still not sure how to exactly reproduce the error. But it only
> happens, when the filesysstem has been used extensively for some time (I
> am doing kernel compilation on that fs).
>
> When I mount the system and then sync, nothing happens. After a full day
> of work with some compiles, I can no longer unmount the fs as the sync
> then blocks.
>
> A btrfs scrub reports no errors. A btrfs check report hundreds of errors:
>
> ...
> Incorrect global backref count on 91295694848 found 1 wanted 2
> backpointer mismatch on [91295694848 16384]
> ref mismatch on [91295711232 16384] extent item 1, found 2
> Incorrect global backref count on 91295711232 found 1 wanted 2
> backpointer mismatch on [91295711232 16384]
> ref mismatch on [91295727616 16384] extent item 1, found 2
> Incorrect global backref count on 91295727616 found 1 wanted 2
> backpointer mismatch on [91295727616 16384]
> ref mismatch on [91295744000 16384] extent item 1, found 2
> Incorrect global backref count on 91295744000 found 1 wanted 2
> backpointer mismatch on [91295744000 16384]
> ref mismatch on [91295760384 16384] extent item 1, found 2
> Incorrect global backref count on 91295760384 found 1 wanted 2
> backpointer mismatch on [91295760384 16384]
> ref mismatch on [91295776768 16384] extent item 1, found 2
> Incorrect global backref count on 91295776768 found 1 wanted 2
> backpointer mismatch on [91295776768 16384]
> ref mismatch on [91295793152 16384] extent item 1, found 2
> Incorrect global backref count on 91295793152 found 1 wanted 2
> backpointer mismatch on [91295793152 16384]
> ref mismatch on [91295809536 16384] extent item 1, found 2
> Incorrect global backref count on 91295809536 found 1 wanted 2
> backpointer mismatch on [91295809536 16384]
> ref mismatch on [91295825920 16384] extent item 1, found 2
> Incorrect global backref count on 91295825920 found 1 wanted 2
> backpointer mismatch on [91295825920 16384]
> Errors found in extent allocation tree or chunk allocation
> checking free space cache
> free space inode generation (0) did not match free space cache
> generation (3272)
> checking fs roots
> checking csums
> checking root refs
> found 42565280463 bytes used err is 0
> total csum bytes: 82221224
> total tree bytes: 3689676800
> total fs tree bytes: 3475308544
> total extent tree bytes: 109215744
> btree space waste bytes: 609518812
> file data blocks allocated: 118278844416
> referenced 117607366656
> Btrfs v3.12
>
> Kernel is 3.14.1, Ubuntu 14.04.
>
> The question is: What shall I do? btrfs check --repair? Or better just
> copy all data to a new fs and delete the partition?
>
> Michael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-05-01 8:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 6:37 task sync:2450 blocked for more than 120 seconds Neuer User
2014-05-01 8:14 ` Neuer User [this message]
2014-05-01 17:16 ` Duncan
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='ljsvpb$cl6$1@ger.gmane.org' \
--to=auslands-kv@gmx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).