Am 29.08.19 um 15:17 schrieb Oliver Freyermuth: > Am 29.08.19 um 15:11 schrieb Qu Wenruo: >> >> >> On 2019/8/29 下午8:46, Oliver Freyermuth wrote: >>> Am 27.08.19 um 14:40 schrieb Hans van Kranenburg: >>>> On 8/27/19 11:14 AM, Swâmi Petaramesh wrote: >>>>> On 8/27/19 8:52 AM, Qu Wenruo wrote: >>>>>>> or to use the V2 space >>>>>>> cache generally speaking, on any machine that I use (I had understood it >>>>>>> was useful only on multi-TB filesystems...) >>>>>> 10GiB is enough to create large enough block groups to utilize free >>>>>> space cache. >>>>>> So you can't really escape from free space cache. >>>>> >>>>> I meant that I had understood that the V2 space cache was preferable to >>>>> V1 only for multi-TB filesystems. >>>>> >>>>> So would you advise to use V2 space cache also for filesystems < 1 TB ? >>>> >>>> Yes. >>>> >>> >>> This makes me wonder if it should be the default? >> >> It will be. >> >> Just a spoiler, I believe features like no-holes and v2 space cache will >> be default in not so far future. >> >>> >>> This thread made me check on my various BTRFS volumes and for almost all of them (in different machines), I find cases of >>> failed to load free space cache for block group XXXX, rebuilding it now >>> at several points during the last months in my syslogs - and that's for machines without broken memory, for disks for which FUA should be working fine, >>> without any unsafe shutdowns over their lifetime, and with histories as short as only having seen 5.x kernels. >> >> That's interesting. In theory that shouldn't happen, especially without >> unsafe shutdown. > > I also forgot to add that in addition on the machines there is no mdraid / dm / LUKS in between (i.e. purely btrfs on the drives). > The messages _seem_ to be more prominent for spinning disks, but after all, my statistics is just 5 devices in total. > So it really "feels" like a bug crawling somewhere. However, the machines seem to not have not seen any actual corruption as consequence. > I'm playing with "btrfs check --readonly" now to see if there's really everything still fine, but I'm already running kernel 5.2 with the new checks without issues. To calm anybody still in fear of the rebuilding warnings: I already checked two disks (including the most affected one) and they were perfectly healthy. So it seems that at least in my cases, the "rebuilding" warning did not (yet?) coincide with any corruption. I have also converted the largest and most affected disk to space_cache=v2 as of now. If that works well in the next weeks, I will look at converting the rest, and if not, I'll be back here ;-). Cheers, Oliver > >> But please also be aware that, there is no concrete proof that corrupted >> v1 space cache is causing all the problems. >> What I said is just, corrupted v1 space cache may cause problem, I need >> to at least craft an image to proof my assumption. > > I see - that might be useful in any case to hopefully track down the issue. > >> >>> >>> So if this may cause harmful side effects, happens without clear origin, and v2 is safer due to being CoW, >>> I guess I should switch all my nodes to v2 (or this should become the default in a future kernel?). >> >> At least, your experience would definitely help the btrfs community. > > Ok, then I will slowly switch the nodes one by one - in case I do not come and cry on the list, this means all is well (but I'm only a small datapoint with 5 disks in three machines) ;-). > > Cheers, > Oliver > >> >> Thanks, >> Qu >> >>> >>> Cheers, >>> Oliver >>>
