From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f43.google.com ([209.85.215.43]:43251 "EHLO mail-lf0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933825AbeBMKWB (ORCPT ); Tue, 13 Feb 2018 05:22:01 -0500 Received: by mail-lf0-f43.google.com with SMTP id q69so6541974lfi.10 for ; Tue, 13 Feb 2018 02:22:00 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <55C1F3DD.7020603@gmail.com> <126f9f09-4e28-3c12-5384-63032e17942f@cn.fujitsu.com> <5cc93522-1bd2-bdc1-d5da-a11d5e4816a7@cn.fujitsu.com> <799054c4-b4f5-2dc0-4f70-4345159d9078@cn.fujitsu.com> <36291cd0-64bc-8708-9e23-0aac30539785@cn.fujitsu.com> From: John Ettedgui Date: Tue, 13 Feb 2018 02:21:58 -0800 Message-ID: Subject: Re: mount btrfs takes 30 minutes, btrfs check runs out of memory To: Qu Wenruo Cc: Austin S Hemmelgarn , btrfs Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Thu, Jul 21, 2016 at 1:19 AM, Qu Wenruo wrote: > > > No more. > > The dump is already good enough for me to dig for some time. > > We don't usually get such large extent tree dump from a real world use case. > > It would help us in several ways, from determine how fragmented a block > group is to determine if a defrag will help. > > Thanks, > Qu > > Hello there, have you found anything good since then? With a default system, the behavior is pretty much still the same, though I have not recreated the partitions since. Defrag helps, but I think balance helps even more. clear_cache may help too, but I'm not really sure as I've not tried it on its own. I was actually able to get a 4TB partition on a 5400rpm HDD to mount in around 500ms, quite faster that even some Gb partitions I have on SSDs! Alas I wrote some files to it and it's taking over a second again, so no more magic there. The workarounds do work, so it's still not a major issue, but they're slow and sometimes I have to workaround the "no space left on device" which then takes even more time. Thank you! John