Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

[John Ettedgui <john.ettedgui@gmail.com>]

On Mon, Aug 3, 2015 at 8:01 PM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
> Oh, converted...
> That's too bad. :(
>
> [[What's wrong with convert]]
> Although btrfs is flex enough in theory to fit itself into the free space of
> ext* and works fine,
> But in practice, ext* is too fragmental in the standard of btrfs, not to
> mention it also enables mixed-blockgroup.
>
Oh oh :/
>
> [[Recommendations]]
> I'd recommend to delete the ext*_img subvolume and rebalance all chunks in
> the fs if you're stick to the converted filesystem.
>
Already done (well the rebalance crashed towards the end both time
with the read only error, but someone on #btrfs looked at my partition
stats and said it was probably good enough)
> Although the best practice is staying away from such converted fs, either
> using pure, newly created btrfs, or convert back to ext* before any balance.
>
Unfortunately I don't have enough hard drive space to do a clean
btrfs, so my only way to use btrfs for that partition was a
conversion.
> [[But before that, just try something]]
> But you have already provided some interesting facts. As the filesystem is
> high fragmented, I'd like to recommend to do some little test:
> (BTW I assume you don't use some special mount options)
Current mount options in fstab:
btrfs   defaults,noatime,compress=lzo,space_cache,autodefrag    0       0
It's the same as my other btrfs partitions, apart from the fact that
they are on a SSD and way smaller.
> To test if it's the space cache causing the mount speed drop.
>
> 1) clear page cache
>    # echo 3 > /proc/sys/vm/drop_caches
> 2) Do a normal mount
>    Just as what you do as usual, with your normal mount options
>    Record the mount time
0.01s user 0.42s system 0% cpu 1:01.70 total
> 3) umount it.
not asked but might as well:
0.00s user 0.65s system 1% cpu 35.536 total
> 4) clear page cache
>    # echo 3 > /proc/sys/vm/drop_caches
> 5) mount it with "clear_cache" mount option
>    It may takes sometime to clear the existing cache.
>    It's just used to clear space cache.
>    Don't compare mount time!
Yes I know it's supposed to be slower :)
although... it was pretty much the same actually:
0.01s user 0.44s system 0% cpu 1:02.07 total
> 6) umount it

> 7) clear page cache
>    # echo 3 > /proc/sys/vm/drop_caches
Is it ok if that value never changed since 1) ?
> 8) mount with "nospace_cache" mount option
>    To see if there is obvious mount time change.
>
0.00s user 0.44s system 0% cpu 1:01.86 total
> Hopes that's the space cache thing causing the slow mount.
> But don't expect it too much anyway, it's just one personal guess.
>
Unfortunately it is about the same :/
> After the test, I'd recommend to follow the [[Recommendations]] if you just
> want a stable filesystem.
>
I am already within these recommendations I think.

Thanks!