On Thu, Apr 2, 2020 at 12:39 PM Paul Dagnelie <p...@delphix.com> wrote:
> I was not entirely surprised to find that btrfs has its own unique > take on what to do with O_DIRECT: > https://btrfs.wiki.kernel.org/index.php/Gotchas#Direct_IO_and_CRCs > "the application will modify the page while it's inflight .. This > results in checksum verification messages that are warnings instead of > errors" > We considered something similar for ZFS, but the problem is that these checksum "warnings" would just be an FYI to the system administrator. ZFS (and surrounding software) couldn't take any action based on these checksum "warnings", because they might or might not indicate bad hardware. For example: we couldn't fail the user's read() syscall with EIO (so we'd be giving them bad data if the hardware actually corrupted it, just like checksum=off); and we couldn't have the fault management code (FMA / ZED) fail the device and spare in a new one. > On Thu, Apr 2, 2020 at 2:20 AM <scine...@gmail.com> wrote: > > > > Regarding modified buffers during writeback how does btrfs handle > o_direct for checksum, compression, raid? What does mdraid do under ext4, > xfs? That MMU setting sounds like a good idea. > The MMU setting (disabling stores while ZFS is processing the write) is a good idea if it performs better than copying the data. Unfortunately, modifying the TLB on all CPU's (aka TLB shootdown) is very expensive. So it might be faster than making a copy if the write is very large (16MB?), but is almost certainly slower for small writes (8K-128K?). But we can re-evaluate this implementation detail as we gather more data and as state-of-the-art hardware performance changes over time. <https://openzfs.topicbox.com/groups/developer/subscription> --matt ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T950b02acdf392290-M50843a49be62ad916415651b Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
