From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EC4DC3A5A9 for ; Sat, 2 May 2020 06:00:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A3AF2137B for ; Sat, 2 May 2020 06:00:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726900AbgEBGAl convert rfc822-to-8bit (ORCPT ); Sat, 2 May 2020 02:00:41 -0400 Received: from james.kirk.hungrycats.org ([174.142.39.145]:42506 "EHLO james.kirk.hungrycats.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726468AbgEBGAl (ORCPT ); Sat, 2 May 2020 02:00:41 -0400 Received: by james.kirk.hungrycats.org (Postfix, from userid 1002) id 0DA6A69FB61; Sat, 2 May 2020 02:00:38 -0400 (EDT) Date: Sat, 2 May 2020 02:00:38 -0400 From: Zygo Blaxell To: Paul Jones Cc: Phil Karn , Jean-Denis Girard , "linux-btrfs@vger.kernel.org" Subject: Re: Extremely slow device removals Message-ID: <20200502060038.GK10769@hungrycats.org> References: <8b647a7f-1223-fa9f-57c0-9a81a9bbeb27@ka9q.net> <14a8e382-0541-0f18-b969-ccf4b3254461@ka9q.net> <20200502033509.GG10769@hungrycats.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sat, May 02, 2020 at 04:48:42AM +0000, Paul Jones wrote: > > -----Original Message----- > > From: linux-btrfs-owner@vger.kernel.org > owner@vger.kernel.org> On Behalf Of Zygo Blaxell > > Sent: Saturday, 2 May 2020 1:35 PM > > To: Phil Karn > > Cc: Jean-Denis Girard ; linux-btrfs@vger.kernel.org > > Subject: Re: Extremely slow device removals > > > > On Fri, May 01, 2020 at 01:05:20AM -0700, Phil Karn wrote: > > > On 4/30/20 11:13, Jean-Denis Girard wrote: > > > > > > > > Hi Phil, > > > > > > > > I did something similar one month ago. It took less than 4 hours for > > > > 1.71 TiB of data: > > > > > > > > [xxx@taina ~]$ sudo btrfs replace status /home/SysNux Started on > > > > 21.Mar 11:13:20, finished on 21.Mar 15:06:33, 0 write errs, 0 > > > > uncorr. read errs > > > > > > I just realized you did a *replace* rather than a *remove*. When I did > > > a replace on another drive, it also went much faster. It must copy the > > > data from the old drive to the new one in larger and/or more > > > contiguous chunks. It's only the remove operation that's painfully slow. > > > > "Replace" is a modified form of scrub which assumes that you want to > > reconstruct an entire drive instead of verifying an existing one. > > It reads and writes all the blocks roughly in physical disk order, and doesn't > > need to update any metadata since it's not changing any of the data as it > > passes through. > > > > "Delete" is resize to 0 followed by remove the empty device. Resize requires > > relocating all data onto other disks--or other locations on the same disk--one > > extent at a time, and updating all of the reference pointers in the filesystem. > > > > The difference in speed can be several orders of magnitude. > > Delete seems to work like a balance. I've had a totally unbalanced > raid 1 array and after removing a single almost full drive all the > remaining drives are magically 50% full, down from 90% and up from > 10%. It's a bit stressful when there is a missing disk as you can only > delete a missing disk, not replace it. Huh? Replacing missing disks is what btrfs replace is _for_. > It would be nice if BTRFS had some more smarts so it knows when to "balance" data, and when to simply "move/copy" a single copy of data. > > > Paul.