qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK


From: Stephane Chazelas
Subject: Re: [Qemu-block] [Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK_DATA/SEEK_HOLE)?
Date: Wed, 8 Feb 2017 14:06:46 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

2017-02-08 00:43:18 +0100, Max Reitz:
[...]
> OTOH, it may make sense to offer a way for the user to disable
> lseek(SEEK_{DATA,HOLE}) in our "file" block driver. That way your issue
> would be solved, too, I guess. I'll look into it.
[...]

Thanks Max,

Yes, that would work for me and other users of ZFS. What I do
for now is recompile with those lseek(SEEK_{DATA,HOLE}) disabled
in the code and it's working fine.

As I already hinted, something that would also possibly work for
me and could benefit everyone (well at least Linux users on
filesystems supporting hole punching), is instead of checking
beforehand if the file is allocated, do a
fallocate(FALLOC_FL_PUNCH_HOLE), or IOW, tell the underlying
layer to deallocate the data.

That would be those two lseek() replaced by a fallocate(), and
some extra disk space being saved.

One may argue that's what one would expect would be done when
using detect-zeroes=unmap. 

I suppose that would be quite significant work as that would
imply a framework to pass those "deallocates" down and you'd
probably have to differenciate "deallocates" that zero (like
hole punching in a reguar file), and those that don't (like
BLKDISCARD on a SSD)

I also suppose that could cause fragmentation that  would be
unwanted in some contexts, so maybe it should be tunable as
well.

-- 
Stephane




reply via email to

[Prev in Thread] Current Thread [Next in Thread]