Bug 1554265
| Summary: | preallocate_images = space is not honoured when using qcow2 | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Martin Schuppert <mschuppe> | |
| Component: | openstack-nova | Assignee: | Lee Yarwood <lyarwood> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | awaugama | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 8.0 (Liberty) | CC: | awaugama, berrange, dasmith, eglynn, jhakimra, kchamart, lyarwood, mbooth, molasaga, pablo.iranzo, sbauza, sferdjao, sgordon, srevivo, ssigwald, vromanso | |
| Target Milestone: | zstream | Keywords: | TestOnly, Triaged, ZStream | |
| Target Release: | 8.0 (Liberty) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | openstack-nova-12.0.6-27.el7ost | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1569952 (view as bug list) | Environment: | ||
| Last Closed: | 2018-09-21 10:36:24 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1569952 | |||
| Bug Blocks: | ||||
|
Description
Martin Schuppert
2018-03-12 09:29:26 UTC
The fallocate behaviour you report is unexpected, and for reference I don't see it on RHEL 7.5: [mbooth@yellow ~]$ fallocate -l 1G test [mbooth@yellow ~]$ ls -lh test -rw-r--r--. 1 mbooth mbooth 1.0G Mar 16 13:06 test [mbooth@yellow ~]$ du -sh test 1.0G test [mbooth@yellow ~]$ python Python 2.7.5 (default, Feb 20 2018, 09:19:12) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.getsize('test') 1073741824 >>> I tested the same on a tmpfs just in case, and the behaviour was the same. (In reply to Matthew Booth from comment #2) > The fallocate behaviour you report is unexpected, and for reference I don't > see it on RHEL 7.5: > > [mbooth@yellow ~]$ fallocate -l 1G test > [mbooth@yellow ~]$ ls -lh test > -rw-r--r--. 1 mbooth mbooth 1.0G Mar 16 13:06 test > [mbooth@yellow ~]$ du -sh test > 1.0G test > [mbooth@yellow ~]$ python > Python 2.7.5 (default, Feb 20 2018, 09:19:12) > [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import os.path > >>> os.path.getsize('test') > 1073741824 > >>> > > I tested the same on a tmpfs just in case, and the behaviour was the same. nova uses the -n option for fallocate 243 utils.execute('fallocate', '-n', '-l', size, self.path) Without using -n the allocation is correct, but with we have the described behavior (In reply to Martin Schuppert from comment #3) > (In reply to Matthew Booth from comment #2) > > The fallocate behaviour you report is unexpected, and for reference I don't > > see it on RHEL 7.5: > > > > [mbooth@yellow ~]$ fallocate -l 1G test > > [mbooth@yellow ~]$ ls -lh test > > -rw-r--r--. 1 mbooth mbooth 1.0G Mar 16 13:06 test > > [mbooth@yellow ~]$ du -sh test > > 1.0G test > > [mbooth@yellow ~]$ python > > Python 2.7.5 (default, Feb 20 2018, 09:19:12) > > [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import os.path > > >>> os.path.getsize('test') > > 1073741824 > > >>> > > > > I tested the same on a tmpfs just in case, and the behaviour was the same. > > nova uses the -n option for fallocate > 243 utils.execute('fallocate', '-n', '-l', size, self.path) > > Without using -n the allocation is correct, but with we have the described > behavior Ah, ha! Then that's the bug. With fallocate -n we're not actually doing the fallocate at all on a qcow2 because it's not a sparse file. (In reply to Matthew Booth from comment #4) > (In reply to Martin Schuppert from comment #3) > > (In reply to Matthew Booth from comment #2) > > > The fallocate behaviour you report is unexpected, and for reference I don't > > > see it on RHEL 7.5: > > > > > > [mbooth@yellow ~]$ fallocate -l 1G test > > > [mbooth@yellow ~]$ ls -lh test > > > -rw-r--r--. 1 mbooth mbooth 1.0G Mar 16 13:06 test > > > [mbooth@yellow ~]$ du -sh test > > > 1.0G test > > > [mbooth@yellow ~]$ python > > > Python 2.7.5 (default, Feb 20 2018, 09:19:12) > > > [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2 > > > Type "help", "copyright", "credits" or "license" for more information. > > > >>> import os.path > > > >>> os.path.getsize('test') > > > 1073741824 > > > >>> > > > > > > I tested the same on a tmpfs just in case, and the behaviour was the same. > > > > nova uses the -n option for fallocate > > 243 utils.execute('fallocate', '-n', '-l', size, self.path) > > > > Without using -n the allocation is correct, but with we have the described > > behavior > > Ah, ha! Then that's the bug. With fallocate -n we're not actually doing the > fallocate at all on a qcow2 because it's not a sparse file. For new created instances a change to the fallocate call could solve the issue, but what about existing instances? As we already use the information from qemu-img info for the virt-size my idea was that we could use the same source for the actual size instead of checking the file via getsize. (In reply to Matthew Booth from comment #4) > (In reply to Martin Schuppert from comment #3) > > Without using -n the allocation is correct, but with we have the described > > behavior > > Ah, ha! Then that's the bug. With fallocate -n we're not actually doing the > fallocate at all on a qcow2 because it's not a sparse file. That's not correct, I've mis-remembered the behaviour of fallocate -n. The bug is that with fallocate -n we are actually allocating the requested size, which reduces disk free by the requisite amount, but *not* increasing the file size. That is a 20G file reports its size as 256k. I believe we should ditch the -n option to fallocate in imagebackend. (In reply to Martin Schuppert from comment #5) > (In reply to Matthew Booth from comment #4) > > (In reply to Martin Schuppert from comment #3) > > > (In reply to Matthew Booth from comment #2) > > > > The fallocate behaviour you report is unexpected, and for reference I don't > > > > see it on RHEL 7.5: > > > > > > > > [mbooth@yellow ~]$ fallocate -l 1G test > > > > [mbooth@yellow ~]$ ls -lh test > > > > -rw-r--r--. 1 mbooth mbooth 1.0G Mar 16 13:06 test > > > > [mbooth@yellow ~]$ du -sh test > > > > 1.0G test > > > > [mbooth@yellow ~]$ python > > > > Python 2.7.5 (default, Feb 20 2018, 09:19:12) > > > > [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2 > > > > Type "help", "copyright", "credits" or "license" for more information. > > > > >>> import os.path > > > > >>> os.path.getsize('test') > > > > 1073741824 > > > > >>> > > > > > > > > I tested the same on a tmpfs just in case, and the behaviour was the same. > > > > > > nova uses the -n option for fallocate > > > 243 utils.execute('fallocate', '-n', '-l', size, self.path) > > > > > > Without using -n the allocation is correct, but with we have the described > > > behavior > > > > Ah, ha! Then that's the bug. With fallocate -n we're not actually doing the > > fallocate at all on a qcow2 because it's not a sparse file. > > For new created instances a change to the fallocate call could solve the > issue, > but what about existing instances? As we already use the information from > qemu-img > info for the virt-size my idea was that we could use the same source for the > actual size instead of checking the file via getsize. We could potentially do that, too, which as you say would avoid having to remediate existing disks. I'll look into both. According to our records, this should be resolved by openstack-nova-12.0.6-28.el7ost. This build is available now. |