diff options
author | Asahi Lina <lina@asahilina.net> | 2024-11-13 04:55:32 +0900 |
---|---|---|
committer | Miklos Szeredi <mszeredi@redhat.com> | 2024-11-18 12:24:38 +0100 |
commit | d1dfb5f52ffc4a142d88da5c0ed0514f3602c4b8 (patch) | |
tree | a441a2f3ef752a0bc6cd4cb07eeda7501e5054c8 /mm | |
parent | 69eb56f69efb866c791cc87fd7bf62adf2ffcbb3 (diff) | |
download | lwn-d1dfb5f52ffc4a142d88da5c0ed0514f3602c4b8.tar.gz lwn-d1dfb5f52ffc4a142d88da5c0ed0514f3602c4b8.zip |
virtiofs: dax: remove ->writepages() callback
When using FUSE DAX with virtiofs, cache coherency is managed by the
host. Disk persistence is handled via fsync() and friends, which are
passed directly via the FUSE layer to the host. Therefore, there's no
need to do dax_writeback_mapping_range(). All that ends up doing is a
cache flush operation, which is not caught by KVM and doesn't do much,
since the host and guest are already cache-coherent.
Since dax_writeback_mapping_range() checks that the inode block size is
equal to PAGE_SIZE, this fixes a spurious WARN when virtiofs is used
with a mismatched guest PAGE_SIZE and virtiofs backing FS block size
(this happens, for example, when it's a tmpfs and the host and guest
have a different PAGE_SIZE). FUSE DAX does not require any particular FS
block size, since it always performs DAX mappings in aligned 2MiB
blocks.
See discussion in [1].
[1] https://lore.kernel.org/lkml/20241101-dax-page-size-v1-1-eedbd0c6b08f@asahilina.net/T/#u
[SzM: remove the empty callback]
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions