From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:36363 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751827AbcGRPbY (ORCPT ); Mon, 18 Jul 2016 11:31:24 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bPAVn-0003lI-I8 for linux-btrfs@vger.kernel.org; Mon, 18 Jul 2016 17:31:16 +0200 Received: from 64.134.221.72 ([64.134.221.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jul 2016 17:31:15 +0200 Received: from 1i5t5.duncan by 64.134.221.72 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jul 2016 17:31:15 +0200 To: linux-btrfs@vger.kernel.org From: Duncan <1i5t5.duncan@cox.net> Subject: Re: mount btrfs takes 30 minutes, btrfs check runs out of memory Date: Mon, 18 Jul 2016 15:31:00 +0000 (UTC) Message-ID: References: <55C02AF9.3070600@cn.fujitsu.com> <55C0A1ED.6020407@gmail.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: Qu Wenruo posted on Mon, 18 Jul 2016 17:07:47 +0800 as excerpted: >> Since I'm really surprised on the mount time reduce, especially >> considering the fact that for compression case, max extent size is >> limited to 128K, IMHO defrag won't help much. >> >> Is the 128K limit for the whole FS or only for files that btrfs deemed >> worth to compress? If it's the latter, that could explain why defrag >> helped. > > The latter. But the 128K is not for compressed size, but raw size. > > So no matter the compressed size, any extent whose uncompressed size is > larger than 128K will be split. > > The main reason I'm surprised about the mount time reduce, is that > considering the sectorsize (4K for x86_64 and x86), the fragments won't > increase too much. > The smallest extent size is determined by sectorsize(4K for most arch). > Compressed extent up limit is 128K, 4K -> 128K is only 32 times. While > for non-compress case, its extent size up limit is 128M. > 32K times larger than sector size, or 1024 times larger than compressed > extent size. > > So I'm quite surprised that defrag helps so much. [I'm only seeing your posts here, not his (yet?), so I'm only seeing what you quote from his posts and may be missing part of the story. Never-the- less...] I think what he's referring to is that he's only running compress, not compress-force, and presumably not autodefrag. So there's probably a lot of uncompressed files that were heavily fragmented and thus in many extents, that a defrag run helped consolidate, thus reducing mount time substantially. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman