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 84707C47247 for ; Sat, 2 May 2020 07:20:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6E238208DB for ; Sat, 2 May 2020 07:20:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726574AbgEBHU5 convert rfc822-to-8bit (ORCPT ); Sat, 2 May 2020 03:20:57 -0400 Received: from james.kirk.hungrycats.org ([174.142.39.145]:35040 "EHLO james.kirk.hungrycats.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726468AbgEBHU4 (ORCPT ); Sat, 2 May 2020 03:20:56 -0400 Received: by james.kirk.hungrycats.org (Postfix, from userid 1002) id E5EEF69FCB9; Sat, 2 May 2020 03:20:53 -0400 (EDT) Date: Sat, 2 May 2020 03:20:53 -0400 From: Zygo Blaxell To: Phil Karn Cc: Paul Jones , Jean-Denis Girard , "linux-btrfs@vger.kernel.org" Subject: Re: Extremely slow device removals Message-ID: <20200502072053.GL10769@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 Fri, May 01, 2020 at 10:25:44PM -0700, Phil Karn wrote: > I'm still not sure I understand what "balance" really does. I've run > it quite a few times, with increasing percentage limits as > recommended, but my drives never end up with equal amounts of data. > Maybe that's because I've got an oddball configuration involving > drives of two different sizes and (temporarily at least) an odd number > of drives. It *sounds* like it ought to do what you describe, but what > I read sounds more like an internal defragmentation operation on data > and metadata storage areas. Is it both? btrfs balance is mostly used to _free_ space (its other major use case is to convert raid profiles). Some raid levels (the mirroring and single profiles) allocate with the goal of equalizing free space on all drives, others (the striping profiles) equalize occupied space on all drives. raid10 does a bit of both. If you have a mixed striping and mirroring profile (e.g. raid5 data with raid1 metadata) then two opposing allocation policies happen at once, and the space used and free on each disk is determined by the two algorithms fighting it out. balance coalesces free space areas into larger contiguous chunks by reallocating all the existing data as if you had copied the files and deleted the originals in logical extent order. Sometimes people call this "defrag free space" but the use of the word "defrag" can be confusing. balance is not btrfs defrag. defrag is concerned with making data extents contiguous, while balance is concerned with making free space contiguous. > On Fri, May 1, 2020 at 9:48 PM Paul Jones wrote: > > > 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. > > 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.