Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1391859

Summary:	[RFE] When creating thick allocated disks on file-based storage, use '-o preallocation=falloc' instead of 'dd' with zeros.
Product:	[oVirt] ovirt-engine	Reporter:	Sahina Bose <sabose>
Component:	BLL.Storage	Assignee:	Denis Chaplygin <dchaplyg>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Kevin Alon Goldblatt <kgoldbla>
Severity:	medium	Docs Contact:
Priority:	high
Version:	4.0.4	CC:	amureini, apinnick, bugs, dchaplyg, fcami, fgarciad, nsoffer, ratamir, sabose, ylavi
Target Milestone:	ovirt-4.2.0	Keywords:	FutureFeature
Target Release:	4.2.0	Flags:	rule-engine: ovirt-4.2+ ratamir: testing_plan_complete- ylavi: planning_ack+ rule-engine: devel_ack+ ratamir: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	New feature greatly reduces the time required to create thick allocated disks on file-based storage.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-20 11:17:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1429286

Description Sahina Bose 2016-11-04 09:23:10 UTC

Description of problem:

Preallocation of images is slow as zero'es are written to the image that is created. "qemu-img create" supports flags 'falloc', 'metadata' and 'full'
Users should be provided option to pass these flags while preallocating the images

Version-Release number of selected component (if applicable):
4.0

How reproducible:
NA

Steps to Reproduce:
NA

Comment 1 Yaniv Kaul 2016-11-06 06:27:53 UTC

From mailing list discussions seems the real value is in switching our 'dd' implementation to using 'falloc' in the qemu-img create command line. It is not exactly a 1:1 mapping (the fact the file system marked entries as allocated has nothing to do with what the underlying storage has performed) - but so is the case with writing zeros...

The metadata allocation for qcow2 is discussed elsewhere (but also, unless file-based, may be of little value unfortunately).

Comment 2 Yaniv Lavi 2016-11-07 12:17:01 UTC

This RFE has come in very late. Can you give some background on this request?
Do you expect this to happen for 4.1?

Comment 3 Sahina Bose 2016-11-07 15:31:26 UTC

(In reply to Yaniv Dary from comment #2)
> This RFE has come in very late. Can you give some background on this request?
> Do you expect this to happen for 4.1?

Customer was experiencing poor performance in pre-allocating disk images and on digging further, we realise the preallocation flags are not used.

If not feasible for 4.1, please move it to another release

Comment 7 Raz Tamir 2017-05-25 18:35:51 UTC

Hi Sahina,

How can we test that this new option to pass flags to qemu-img?

Comment 8 Sahina Bose 2017-07-07 09:03:28 UTC

(In reply to Raz Tamir from comment #7)
> Hi Sahina,
> 
> How can we test that this new option to pass flags to qemu-img?

I don't this fix uses qemu-img create, but calls posix_fallocate to preallocate.
Denis can provide more info

Comment 9 Nir Soffer 2017-07-12 11:06:39 UTC

Raz, we should test this feature by timing creation of a new preallocated disk on
file storage.

The result differ, based on the underlying file system:
- NFS 3,4,4.1 - use emulation, should be about 1.5X faster compared with older 
  version using dd (we cannot guarantee exact number).
- NFS 4.2,glusterfs,localfs - should take no time, using fallocate()

This is basically a user experience thing, so we should test this from the point of
view of a user.

Comment 10 Denis Chaplygin 2017-07-12 14:32:27 UTC

(In reply to Sahina Bose from comment #8)
> (In reply to Raz Tamir from comment #7)
> > Hi Sahina,
> > 
> > How can we test that this new option to pass flags to qemu-img?
> 
> I don't this fix uses qemu-img create, but calls posix_fallocate to
> preallocate.


Yes, we use posix_fallocate here. Nir provided a good approach to test that issue.

Comment 15 Kevin Alon Goldblatt 2017-08-17 14:37:43 UTC

(In reply to Denis Chaplygin from comment #14)
> Could you please try nfsv4, glusterfs or any local fs? Nfsv3 doesn't
> supports that syscall.
> 
> It definitely works with gluster, so i recommend verifying on it.

Created the same 10G with Glusterfs and the latest code:


>>>>>> It took 7 seconds


Verified with the following code:
---------------------------------------------------
ovirt-engine-4.2.0-0.0.master.20170813134654.gitaee967b.el7.centos.noarch
vdsm-4.20.2-77.gite43f776.el7.centos.x86_64


Moving to VERIFIED!

Comment 16 Sandro Bonazzola 2017-12-20 11:17:40 UTC

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.