Re: btrfs and write barriers

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

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



On 2019/4/4 上午2:17, Hendrik Friedel wrote:
> Hello,
> 
> thanks for your reply.
> 
>>> 3) Even more, it would be good, if btrfs would disable the write cache
>>> in that case, so that one does not need to rely on the user
>>  
>> Personally speaking, if user really believes it's write cache causing
>> the problem or want to be extra safe, then they should disable cache.
> How many percent of the users will be able to judge that?

No need, unless user really got a faulty device.
And in that case, even experienced developer can't easily spot such
problem, so it doesn't really matter until it happens.

>> As long as FLUSH is implemented without problem, the only faulty part is
>> btrfs itself and I haven't found any proof of either yet.
> But you have searched?

Yes, using dm-log-write with various workload, to ensure btrfs does the
correct barrier/fua to ensure metadata is CoWed between transaction.

> 
>>>2) I find the location of the (only?) warning -dmesg- well hidden. I
> think it would be better to notify the user when creating the file-system.

As stated already, unless user got a faulty device, enabling write cache
won't cause any problem.
You guys are spending tons of attention to solve a problem that almost
nobody hits.

Thanks,
Qu

>>A notification on creating the volume and ones when adding devices
> (either via `device add` or via a replace operation) 
>>would indeed be nice, but we should still keep the kernel log warning. 
> 
> Ok, so what would be the way to move forward on that? Would it help if I
> create an issue in a https://bugzilla.kernel.org/ ?
> 
>>>3) Even more, it would be good, if btrfs would disable the write cache
> in that case, so that one does not need to rely on the user
>> I would tend to disagree here. We should definitely _recommend_ this
> to the user if we know there is no barrier support, but just 
>> doing it behind their back is not a good idea.
> 
> Well, there is some room between 'automatic' and 'behind their back. E.g.
> "Barriers are not supported by /dev/sda. Automatically disabling
> write-cache on mount. You can suppress this with the
> 'enable-cache-despite-no-barrier-support-I-know-what-I-am-doing' mount
> option (maybe, we can shorten the option). 
> 
>> There are also plenty of valid reasons to want to use the write cache
> anyway.
> I cannot think of one. Who would sacrifice data integrity/potential
> total loss of the filesystem for speed?
> 
>> As far as FUA/DPO, I know of exactly _zero_ devices that lie about
> implementing it and don't. 
> ...
>> but the fact that Linux used to not issue a FLUSH command to the disks
> when you called fsync in userspace.
> Ok, thanks for that clarification.
> 
> 
> Greetings,
> Hendrik
> 


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