I appreciate the information. Honestly, after applying the solution posted here so it mounts successfully on bootup I was only really concerned if this was normal behavior or not. The longer mount time is an acceptable price to pay for the features I get out of btrfs as long as it is not indicative of an actual problem. I did convert to space_cache=v2 as part of my testing on trying to reduce mount times, it took a few minutes to generate the new cache. I'd say mount times were reduced by 10-15%. I'll keep an eye on the mailing list and on the updates released and hope this improves in the future. Thanks for all the assistance. On Fri, Apr 3, 2020 at 7:02 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, Apr 2, 2020 at 8:36 PM Helper Son <helperson2000@xxxxxxxxx> wrote: > > > Thanks for the suggestion, the main problem is fixed on my end. At > > this point I'm just wandering if taking this long to mount is normal > > behavior and if there is anything else I can do to reduce the time, > > but I suppose it's part of how btrfs works. > > It's normal on large file systems. There is work in progress to make > this faster, but I'm not sure when it'll be merged. I think this does > some short cuts when reading the chunk and extent trees at mount time. > > You could try switching to space_cache=v2 if you aren't already using > it. It's safe to do: mount -o remount,clear_cache,space_cache=v2. > Usually the rebuild goes fast, on 1T file system. Maybe it takes a > minute on a 20T file system? Just a guess. I can't estimate how much > it'll improve mount time, but it should somewhat at least. > > > > -- > Chris Murphy
