On 2018年02月16日 00:30, Ellis H. Wilson III wrote: > On 02/15/2018 06:12 AM, Hans van Kranenburg wrote: >> On 02/15/2018 02:42 AM, Qu Wenruo wrote: >>> Just as said by Nikolay, the biggest problem of slow mount is the size >>> of extent tree (and HDD seek time) >>> >>> The easiest way to get a basic idea of how large your extent tree is >>> using debug tree: >>> >>> # btrfs-debug-tree -r -t extent <device> >>> >>> You would get something like: >>> btrfs-progs v4.15 >>> extent tree key (EXTENT_TREE ROOT_ITEM 0) 30539776 level 0 <<< >>> total bytes 10737418240 >>> bytes used 393216 >>> uuid 651fcf0c-0ffd-4351-9721-84b1615f02e0 >>> >>> That level is would give you some basic idea of the size of your extent >>> tree. >>> >>> For level 0, it could contains about 400 items for average. >>> For level 1, it could contains up to 197K items. >>> ... >>> For leven n, it could contains up to 400 * 493 ^ (n - 1) items. >>> ( n <= 7 ) >> >> Another one to get that data: >> >> https://github.com/knorrie/python-btrfs/blob/master/examples/show_metadata_tree_sizes.py >> >> >> Example, with amount of leaves on level 0 and nodes higher up: >> >> -# ./show_metadata_tree_sizes.py / >> ROOT_TREE 336.00KiB 0( 20) 1( 1) >> EXTENT_TREE 123.52MiB 0( 7876) 1( 28) 2( 1) >> CHUNK_TREE 112.00KiB 0( 6) 1( 1) >> DEV_TREE 80.00KiB 0( 4) 1( 1) >> FS_TREE 1016.34MiB 0( 64113) 1( 881) 2( 52) >> CSUM_TREE 777.42MiB 0( 49571) 1( 183) 2( 1) >> QUOTA_TREE 0.00B >> UUID_TREE 16.00KiB 0( 1) >> FREE_SPACE_TREE 336.00KiB 0( 20) 1( 1) >> DATA_RELOC_TREE 16.00KiB 0( 1) > > Very helpful information. Thank you Qu and Hans! > > I have about 1.7TB of homedir data newly rsync'd data on a single > enterprise 7200rpm HDD and the following output for btrfs-debug: > > extent tree key (EXTENT_TREE ROOT_ITEM 0) 543384862720 level 2 > total bytes 6001175126016 > bytes used 1832557875200 > > Hans' (very cool) tool reports: > ROOT_TREE 624.00KiB 0( 38) 1( 1) > EXTENT_TREE 327.31MiB 0( 20881) 1( 66) 2( 1)
Extent tree is not so large, a little unexpected to see such slow mount. BTW, how many chunks do you have? It could be checked by: # btrfs-debug-tree -t chunk <device> | grep CHUNK_ITEM | wc -l Unless we have tons of chunks, it should be too slow. > CHUNK_TREE 208.00KiB 0( 12) 1( 1) > DEV_TREE 144.00KiB 0( 8) 1( 1) > FS_TREE 5.75GiB 0(375589) 1( 952) 2( 2) 3( 1) > CSUM_TREE 1.75GiB 0(114274) 1( 385) 2( 1) > QUOTA_TREE 0.00B > UUID_TREE 16.00KiB 0( 1) > FREE_SPACE_TREE 0.00B > DATA_RELOC_TREE 16.00KiB 0( 1) > > Mean mount times across 5 tests: 4.319s (stddev=0.079s) > > Taking 100 snapshots (no changes between snapshots however) of the above > subvolume doesn't appear to impact mount/umount time. 100 unmodified snapshots won't affect mount time. It needs new extents, which can be created by overwriting extents in snapshots. So it won't really cause much difference if all these snapshots are all unmodified. > Snapshot creation > and deletion both operate at between 0.25s to 0.5s. IIRC snapshot deletion is delayed, so the real work doesn't happen when "btrfs sub del" returns. Thanks, Qu > I am very impressed > with snapshot deletion in particular now that qgroups is disabled. > > I will do more mount testing with twice and three times that dataset and > see how mount times scale. > > All done on 4.5.5. I really need to move to a newer kernel. > > Best, > > ellis
signature.asc
Description: OpenPGP digital signature
