Sorry for the late reply.
[Slow mount]
In fact we also reproduce the same problem, and found the problem.
It's related to the size of extent tree.
If the extent tree is large enough, mount needs to do quite a lot of IO
to read out all block group items.
And such read is random small read (default leaf size is just 16K), and
considering the per GB cost, spinning rust is the normal choice for such
large fs, which makes random small read even more slower.
The good news is, we have patch to slightly speedup the mount, by
avoiding reading out unrelated tree blocks.
In our test environment, it takes 15% less time to mount a fs filled
with 16K files(2T used space).
https://patchwork.kernel.org/patch/9021421/
And according to the facts that only extent size is related to the
problem, any method to reduce extent tree size will help, including
defrag, nodatacow.
[Btrfsck OOM]
Lu Fengqi is developing btrfsck low memory usage mode.
It's not merged into mainline btrfs progs and not fully completely, but
shows quite positive result for large fs.
It may needs sometime to get it stable, but IMHO it's going the right
direction.
Thanks,
Qu
At 07/12/2016 04:31 AM, John Ettedgui wrote:
On Wed, Aug 5, 2015 at 4:30 AM Austin S Hemmelgarn <ahferro...@gmail.com
<mailto:ahferro...@gmail.com>> wrote:
Yeah, you're probably better off getting a TB disk and starting with
that. In theory it is possible to automate the process, but I would
advise against that if at all possible, it's a lot easier to recover
from an error if you're doing it manually.
Hello,
Has there been any progress on this issue?
My btrfs partitions are now all cleanly made, not converted from ext4,
and yet they still take up to 30s to mount. Interestingly they're all
about the same size, but some take quite longer than others.. I guess
differences FS related.
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
