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
>
