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