Re: BTRFS and databases

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2761 bytes --]



On 2018年08月02日 18:45, Andrei Borzenkov wrote:
> 
> 
> Отправлено с iPhone
> 
>> 2 авг. 2018 г., в 10:02, Qu Wenruo <quwenruo.btrfs@gmx.com> написал(а):
>>
>>
>>
>>> On 2018年08月01日 11:45, MegaBrutal wrote:
>>> Hi all,
>>>
>>> I know it's a decade-old question, but I'd like to hear your thoughts
>>> of today. By now, I became a heavy BTRFS user. Almost everywhere I use
>>> BTRFS, except in situations when it is obvious there is no benefit
>>> (e.g. /var/log, /boot). At home, all my desktop, laptop and server
>>> computers are mainly running on BTRFS with only a few file systems on
>>> ext4. I even installed BTRFS in corporate productive systems (in those
>>> cases, the systems were mainly on ext4; but there were some specific
>>> file systems those exploited BTRFS features).
>>>
>>> But there is still one question that I can't get over: if you store a
>>> database (e.g. MySQL), would you prefer having a BTRFS volume mounted
>>> with nodatacow, or would you just simply use ext4?
>>>
>>> I know that with nodatacow, I take away most of the benefits of BTRFS
>>> (those are actually hurting database performance – the exact CoW
>>> nature that is elsewhere a blessing, with databases it's a drawback).
>>> But are there any advantages of still sticking to BTRFS for a database
>>> albeit CoW is disabled, or should I just return to the old and
>>> reliable ext4 for those applications?
>>
>> Since I'm not a expert in database, so I can totally be wrong, but what
>> about completely disabling database write-ahead-log (WAL), and let
>> btrfs' data CoW to handle data consistency completely?
>>
> 
> This would make content of database after crash completely unpredictable, thus making it impossible to reliably roll back transaction.

Btrfs itself (with datacow) can ensure the fs is updated completely.

That's to say, even a crash happens, the content of the fs will be the
same state as previous btrfs transaction (btrfs sync).

Thus there is no need to rollback database transaction though.
(Unless database transaction is not sync to btrfs transaction)

Thanks,
Qu

> 
> 
>> If there is some concern about the commit interval, it could be tuned by
>> commit= mount option.
>>
>> It may either lead to super unexpected fast behavior, or some unknown
>> disaster. (And for latter, we at least could get some interesting
>> feedback and bugs to fix)
>>
>> Thanks,
>> Qu
>>
>>>
>>>
>>> Kind regards,
>>> MegaBrutal
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]