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 >
signature.asc
Description: OpenPGP digital signature
