From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f50.google.com ([209.85.215.50]:45568 "EHLO mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbeBUV1h (ORCPT ); Wed, 21 Feb 2018 16:27:37 -0500 Received: by mail-lf0-f50.google.com with SMTP id x196so4411573lfd.12 for ; Wed, 21 Feb 2018 13:27:36 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <4d705301-c3a1-baaa-3eb8-f7b92f12f505@panasas.com> <27ee5e0b-4127-e890-1322-a31bd62e2412@suse.com> <0c3fb0bb-6fd1-67f6-1c74-3ee98ae15303@gmx.com> <0fa921f1-9a54-e410-1305-c88136f4823c@mendix.com> <5773ab23-8bee-1434-522b-231c154c4c6e@panasas.com> <5743750c-644d-9160-c0f3-599caf92dcb6@panasas.com> <4590b70e-2be7-b511-1428-685dcf2c26c6@gmx.com> From: E V Date: Wed, 21 Feb 2018 16:27:34 -0500 Message-ID: Subject: Re: Status of FST and mount times To: "Ellis H. Wilson III" Cc: Qu Wenruo , "Austin S. Hemmelgarn" , Hans van Kranenburg , Nikolay Borisov , linux-btrfs Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Wed, Feb 21, 2018 at 9:49 AM, Ellis H. Wilson III wrote: > On 02/20/2018 08:49 PM, Qu Wenruo wrote: >>>>> >>>>> On 2018年02月16日 22:12, Ellis H. Wilson III wrote: >>>>>> >>>>>> $ sudo btrfs-debug-tree -t chunk /dev/sdb | grep CHUNK_ITEM | wc -l >>>>>> 3454 >>>>> >>>>> >> Increasing node size may reduce extent tree size. Although at most >> reduce one level AFAIK. >> >> But considering that the higher the node is, the more chance it's >> cached, reducing tree height wouldn't bring much performance impact AFAIK. >> >> If one could do real world benchmark to beat or prove my assumption, it >> would be much better though. > > > I'm willing to try this if you tell me exactly what you'd like me to do. > I've not mucked with nodesize before, so I'd like to avoid changing it to > something absurd. mkfs.btrfs caps -n at 64K so absurd isn't really an option. If you have a large filesystem on a RAID array you will likely see a performance bump in your metadata operations if you use 64K and also set the stripe size of the RAID array to 64K. >>> Qu's suggestion is actually independent of all the above reasons, but >>> does kind of fit in with the fourth as another case of preventative >>> maintenance. >> >> >> My suggestion is to use balance to reduce number of block groups, so we >> could do less search at mount time. >> >> It's more like reason 2. >> >> But it only works for case where there are a lot of fragments so a lot >> of chunks are not fully utilized. >> Unfortunately, that's not the case for OP, so my suggestion doesn't make >> sense here. > > > I ran the balance all the same, and the number of chunks has not changed. > Before 3454, and after 3454: > $ sudo btrfs-debug-tree -t chunk /dev/sdb | grep CHUNK_ITEM | wc -l > 3454 > > HOWEVER, the time to mount has gone up somewhat significantly, from 11.537s > to 16.553s, which was very unexpected. Output from previously run commands > shows the extent tree metadata grew about 25% due to the balance. > Everything else stayed roughly the same, and no additional data was added to > the system (nor snapshots taken, nor additional volumes added, etc): > > Before balance: > $ sudo ./show_metadata_tree_sizes.py /mnt/btrfs/ > ROOT_TREE 1.14MiB 0( 72) 1( 1) > EXTENT_TREE 644.27MiB 0( 41101) 1( 131) 2( 1) > CHUNK_TREE 384.00KiB 0( 23) 1( 1) > DEV_TREE 272.00KiB 0( 16) 1( 1) > FS_TREE 11.55GiB 0(754442) 1( 2179) 2( 5) 3( 2) > CSUM_TREE 3.50GiB 0(228593) 1( 791) 2( 2) 3( 1) > QUOTA_TREE 0.00B > UUID_TREE 16.00KiB 0( 1) > FREE_SPACE_TREE 0.00B > DATA_RELOC_TREE 16.00KiB 0( 1) > > After balance: > $ sudo ./show_metadata_tree_sizes.py /mnt/btrfs/ > ROOT_TREE 1.16MiB 0( 73) 1( 1) > EXTENT_TREE 806.50MiB 0( 51419) 1( 196) 2( 1) > CHUNK_TREE 384.00KiB 0( 23) 1( 1) > DEV_TREE 272.00KiB 0( 16) 1( 1) > FS_TREE 11.55GiB 0(754442) 1( 2179) 2( 5) 3( 2) > CSUM_TREE 3.49GiB 0(227920) 1( 804) 2( 2) 3( 1) > QUOTA_TREE 0.00B > UUID_TREE 16.00KiB 0( 1) > FREE_SPACE_TREE 0.00B > DATA_RELOC_TREE 16.00KiB 0( 1) > >> BTW, if OP still wants to try something to possibly to reduce mount time >> with same the fs, I could try some modification to current block group >> iteration code to see if it makes sense. > > > I'm glad to try anything if it's helpful to improving BTRFS. Just let me > know. > > Best, > > ellis > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html