On 02/24/2014 02:58 PM, Marc MERLIN wrote:
On Mon, Feb 24, 2014 at 06:42:30AM +0000, Duncan wrote:
I believe there's a fix coming (a cancel that blows away the tracking
file if it finds it and no actual running scrub is the most obvious fix),
but meanwhile, see the /var/lib/btrfs/scrub.status.* files. That's where
scrub state is stored, and manually blowing away the appropriate file
should clear btrfs' memory of the aborted scrub, so you can scrub start
properly.
Ah, silly me, I thought this was all in the kernel and not in userspace.
Yep, I cleared the stats, and that part is back to ok, thanks.
I'm not getting btrfs hang on /mnt/btrfs_pool2 after reboot, so that's good.
But I'm still seeing these, albeit less often.
Any idea what they could be linked to?
(I have a btrs send/receive going right now, it could hanging /mnt/btrfs_pool1
I noticed scrub for /mnt/btrfs_pool1 is running more than 10000s....
Not sure if it is related to send/receive, but if you are still runing
send/receive,
just terminate it and let's see if things will become better.
Also Josef gave a patch that can speed up send/receive a lot which has been
pused into btrfs-next, you can try it.
Thanks,
Wang
in a way that affects smbd, but the array feels ok otherwise, weird...)
--
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
