On Tue 25-07-17 14:15:22, Christoph Hellwig wrote:
On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote:
> On Tue 25-07-17 10:01:58, Christoph Hellwig wrote:
> > On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote:
> > > I guess it's up to filesystem if it wants to reuse the same spot to
> > > data or not. I think your assumptions works for ext4 and xfs. I
> > > 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...
Jan Kara <jack(a)suse.com>
SUSE Labs, CR