Re: [Qemu-devel] semantics of FIEMAP without FIEMAP_FLAG_SYNC (was Re: [PATCH v5 13/14] nbd: Implement NBD_CMD_WRITE_ZEROES on server)

[Paolo Bonzini <pbonzini@redhat.com>]

> > 1) is it expected that SEEK_HOLE skips unwritten extents?
> 
> There are multiple answers to this, all of which are correct depending
> on current context and state:
> 
> 1. No - some filesystems will report clean unwritten extents as holes.
> 
> 2. Yes - some filesystems will report clean unwritten extents as data.
> 
> 3.  Maybe - if there is written data in memory over the unwritten
> extent on disk (i.e. hasn't been flushed to disk, it will be
> considered a data region with non-zero data. (FIEMAP will still
> report is as unwritten)

Ok, I thought it would return FIEMAP_EXTENT_UNKNOWN|FIEMAP_EXTENT_DELALLOC
in this case (not FIEMAP_EXTENT_UNWRITTEN).

> > If not, would
> > it be acceptable to introduce Linux-specific SEEK_ZERO/SEEK_NONZERO, which
> > would be similar to what SEEK_HOLE/SEEK_DATA do now?
> 
> To solve what problem? You haven't explained what problem you are
> trying to solve yet.
> 
> > 2) for FIEMAP do we really need FIEMAP_FLAG_SYNC?  And if not, for what
> > filesystems and kernel releases is it really not needed?
> 
> I can't answer this question, either, because I don't know what
> you want the fiemap information for.

The answer is the same no matter if we use both lseek and FIEMAP, so
I'll answer just once.  We want to do two things:

1) avoid copying zero data, to keep the copy process efficient.  For this,
SEEK_HOLE/SEEK_DATA are enough.

2) copy file contents while preserving the allocation state of the file's extents.
There can be various reasons why the user has preallocated the file (because they
don't want an ENOSPC to happen while the VM runs; on some filesystems, to
minimize cases where io_submit is very un-asynchronous; or just because someone
had a reason to do a BLKZEROOUT ioctl on the virtual disk).  We want to preserve
these while converting or otherwise moving the file around.

Preallocation can result in unwritten extents in various cases.  Of course, it is
often a simple fallocate on the host.  However, when the guest sends a BLKZEROOUT
ioctl that will also be converted by QEMU into fallocate(FALLOC_FL_ZERO_RANGE) or
ioctl(XFS_IOC_ZERO_RANGE).  In this case in fact the user could be preallocating
only part of the disk.

Paolo