At 07/18/2016 04:20 PM, John Ettedgui wrote:
On Sun, Jul 17, 2016 at 6:14 PM Qu Wenruo <quwen...@cn.fujitsu.com
<mailto:quwen...@cn.fujitsu.com>> wrote:
Well, compression=no only affects any write after the mount option.
And balance won't help to convert compressed extent to
non-compressed one.
But maybe the defrag will convert them to normal extents.
The best method to de-compress them is, to read them out and rewrite
them with compression=no mount option.
Right, I just don't have the extra storage for that right now, though I
suppose I could do little by little, but manually that would take a
really long time, so I went with the defrag route :)
>
> I'll try just defragmenting another partition but keeping the
> compression on and see what difference I get there the same changes.
>
So following that, another partition got its mounting time reduced by
about 70% by running a manual defrag (I kept compression on and used
-clzo for this defragmentation).
So maybe a manual defrag is really the best thing to do so far.
Seems to be the case.
For further investigation, it would be quite nice for you to upload the
output of "btrfs-debug-tree -t 2" dump of your fs.
Both before and after, and it doesn't containing anything meaningful(no
file name/relation, only extent allocation info), so it's should be
quite safe to upload.
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.
> I've tried the patch, which applied fine to my kernel (4.6.4) but I
> don't see any difference in mounting time, maybe I made a mistake
or my
> issue is not really the same?
Pretty possible that there is another problem causing the slow mount.
The best method to verify is to do a ftrace on the btrfs mount.
Here is the script I tested my patch:
....
....
Thank you for the script, that makes it a lot easier for me!
And you can see open_ctree() function, the main part of btrfs mount,
takes about 7.67 seconds to execute, while btrfs_read_block_groups()
takes 7.56 seconds, about 98.6% of the open_ctree() executing time.
If your result are much the same as mine, then that's the same problem.
They are similar, 99% is spent in btrfs_read_block_groups.
And after applying my patch, please try to compare the executing time of
btrfs_read_block_groups() to see if there is any obvious(>5%) change.
Here's what I have for one partition:
no patch:
open_ctree: 16952419
btrfs_read_block_groups: 16844453
ratio: 0.9936312333950689
patch:
open_ctree: 16680173
btrfs_read_block_groups: 16600532
ratio: 0.9952254092328659
ratio no patch/patch: 0.9983981761086407
OK, almost no improvement. So in your case, most BLOCK_GROUP_ITEMS are
not at the tail of a extent tree leaf.
And in our test environment, it seems that quite some BLOCK_GROUPS_ITEMS
are at the tail of an extent tree leaf, and make the improvement quite
obvious.
But anyway, if we can change the on-disk format to introduce a specific
block group items tree, then I assume the mount time would reduce to
less than 5 seconds.
Thanks,
Qu
Thank you,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
