http://bugzilla.opensuse.org/show_bug.cgi?id=1052419 http://bugzilla.opensuse.org/show_bug.cgi?id=1052419#c4 Jeff Mahoney <jeffm@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS CC| |pg@suse.for.sabi.co.uk Flags| |needinfo?(pg@suse.for.sabi. | |co.uk) --- Comment #4 from Jeff Mahoney <jeffm@suse.com> --- (In reply to Peter Grandi from comment #0)
* Btrfs does not compute checksums on write in the case of O_DIRECT IO, and does not provide "stable writes" either, because they are enabled only through the regular IO mechanism.
* The 'nfs-kernel-server' does not use the regular IO mechanism either, so it has the same issues as O_DIRECT and should not be used to export Btrfs filesystems unless for read-only mode.
What is your analysis for this? The only reference you've provided is the btrfs wiki that you've edited yourself to reflect this position.
The overall effect is not that data will be corrupted (usually, even if the lack of "stable writes" is an issue) but that checksums will be missing on data written via 'nfs-kernel-server' and this makes the system less resilient and causes baffling warnings to appear in logs.
Reading through the NFSD code, it's pretty clear that it *doesn't* use direct I/O or anything like it. There are two write paths in btrfs: direct i/o or not. For it to be direct i/o, O_DIRECT needs to be set when the file is opened. NFSD doesn't do that, even if the remote client does. It goes through the buffered write path, that just doesn't happen to start at sys_write because it *shouldn't* since it's internal I/O. The pages are properly copied off via __btrfs_buffered_write well before any I/O is initiated or CRCs are computed. The case where racing direct i/o threads could potentially introduce a similar issue may exist, but that is a *very* specific case that should not be extrapolated to include "all NFS writes" without well-documented and correct analysis. In any case, even if the issue was as you described, the solution would be to correct the spurious warnings, not exchange the well-supported NFS server that we have many man-years of experience maintaining for a relatively new userspace project. There are use cases for Ganesha, but this isn't one of them. What does your analysis show? -- You are receiving this mail because: You are on the CC list for the bug.