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. 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. > > 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. Thanks, Qu > > Cheers, > Oliver >
