From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:30674 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932067AbaICMhk (ORCPT ); Wed, 3 Sep 2014 08:37:40 -0400 Message-ID: <54070B5F.20100@fb.com> Date: Wed, 3 Sep 2014 08:36:47 -0400 From: Chris Mason MIME-Version: 1.0 To: john terragon CC: Subject: Re: kernel 3.17-rc3: task rsync:2524 blocked for more than 120 seconds References: <540498AF.6030109@fb.com> <54062424.9040508@fb.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 09/02/2014 09:31 PM, john terragon wrote: > Rsync finished. FWIW in the end it reported an average speed of about > 900K/sec. Without autodefrag there have been no messages about hung > kworkers even though rsync seemingly keeps getting hung for several > minutes throughout the whole execution. So lets take a step back and figure out how fast the usb stick actually is. This will erase your usb stick, but give us an idea of its performance: dd if=/dev/zero of=/dev/ bs=20M oflag=direct count=100 Note again, the above command will erase your usb stick ;) Use whatever device name you've been sending to mkfs.btrfs The kernel will allow a pretty significant amount of ram to be dirtied before forcing writeback, which is why you're seeing rsync stall at seemingly strange intervals. In the base of btrfs with compression, we add some worker threads between rsync and the device, and these may be turning the writeback into a somewhat more bursty operation. -chris