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.
> 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
>>
