Re: [PATCH v2] btrfs: always fallback to buffered write if the inode requires checksum

Re: [PATCH v2] btrfs: always fallback to buffered write if the inode requires checksum

[hch]

On Tue, Feb 04, 2025 at 02:00:23PM +1030, Qu Wenruo wrote:
> [BUG]
> It is a long known bug that VM image on btrfs can lead to data csum
> mismatch, if the qemu is using direct-io for the image (this is commonly
> known as cache mode none).
> 
> [CAUSE]
> Inside the VM, if the fs is EXT4 or XFS, or even NTFS from Windows, the
> fs is allowed to dirty/modify the folio even the folio is under
> writeback (as long as the address space doesn't have AS_STABLE_WRITES
> flag inherited from the block device).

Btw, can you add an xfstests that reproduces this by modifying pages
under direct I/O?  That would be really helpful to verify the code when
we want to turn back on real direct I/O eventually when the VM is fixed
to prevent the modifications.

Re: [PATCH v2] btrfs: always fallback to buffered write if the inode requires checksum

[Qu Wenruo]

在 2025/2/7 00:43, hch@infradead.org 写道:
> On Tue, Feb 04, 2025 at 02:00:23PM +1030, Qu Wenruo wrote:
>> [BUG]
>> It is a long known bug that VM image on btrfs can lead to data csum
>> mismatch, if the qemu is using direct-io for the image (this is commonly
>> known as cache mode none).
>>
>> [CAUSE]
>> Inside the VM, if the fs is EXT4 or XFS, or even NTFS from Windows, the
>> fs is allowed to dirty/modify the folio even the folio is under
>> writeback (as long as the address space doesn't have AS_STABLE_WRITES
>> flag inherited from the block device).
>
> Btw, can you add an xfstests that reproduces this by modifying pages
> under direct I/O?  That would be really helpful to verify the code when
> we want to turn back on real direct I/O eventually when the VM is fixed
> to prevent the modifications.

Sure, although I'm afraid it will need to be a C program instead.

Thanks,
Qu