Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite()
From: Jan Kara <jack@suse.cz>
Date: 2017-07-25 12:50:37
Also in:
linux-ext4, linux-fsdevel, linux-mm, lkml, nvdimm
From: Jan Kara <jack@suse.cz>
Date: 2017-07-25 12:50:37
Also in:
linux-ext4, linux-fsdevel, linux-mm, lkml, nvdimm
On Tue 25-07-17 14:15:22, Christoph Hellwig wrote:
On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote:quoted
On Tue 25-07-17 10:01:58, Christoph Hellwig wrote:quoted
On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote:quoted
I guess it's up to filesystem if it wants to reuse the same spot to write data or not. I think your assumptions works for ext4 and xfs. I wouldn't be that sure for btrfs or other filesystems with CoW support.Or XFS with reflinks for that matter. Which currently can't be combined with DAX, but I had a somewhat working version a few month ago.But in cases like COW when the block mapping changes, the process must run unmap_mapping_range() before installing the new PTE so that all processes mapping this file offset actually refault and see the new mapping. So this would go through pte_none() case. Am I missing something?Yes, for DAX COW mappings we'd probably need something like this, unlike the pagecache COW handling for which only the underlying block change, but not the page.
Right. So again nothing where the WARN_ON should trigger. That being said I don't care about the WARN_ON too deeply but it can help to catch DAX bugs so if we can keep it I'd prefer to do so... Honza -- Jan Kara [off-list ref] SUSE Labs, CR