I wasn't sure what you meant with <wherever you mkfs btrfs> so I dd'd all the three possible cases:
1) here's the dmcrypt device on which I mkfs.btrfs 2097152000 bytes (2.1 GB) copied, 487.265 s, 4.3 MB/s 2) here's the partition of the usb stick (which has another partition containing /boot) on top of which the dmcrypt device is created 2097152000 bytes (2.1 GB) copied, 449.693 s, 4.7 MB/s 3) here's the whole usb stick device 2097152000 bytes (2.1 GB) copied, 448.003 s, 4.7 MB/s It's a usb2 device but doesn't it seem kind of slow? Thanks John On Wed, Sep 3, 2014 at 2:36 PM, Chris Mason <c...@fb.com> wrote: > 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/<wherever you mkfs btrfs> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
