Bug 471356 - [NetApp 6.0 feat] No intelligence in block/filesystem layer to free space
[NetApp 6.0 feat] No intelligence in block/filesystem layer to free space
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: rc
: 6.0
Assigned To: chellwig@redhat.com
Evan McNabb
: FutureFeature, OtherQA
Depends On:
Blocks: 217209 554559
  Show dependency treegraph
Reported: 2008-11-13 03:04 EST by Ritesh Raj Sarraf
Modified: 2013-06-19 21:56 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 729628 (view as bug list)
Last Closed: 2010-11-11 11:02:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ritesh Raj Sarraf 2008-11-13 03:04:58 EST
Description of problem:

Use Case:
I create a VM for which the device being used is a sparse file. I don't allocate the full space to the file, thus having holes in it. They will fill up as the VM
starts consuming more and more space. Let's assume the file size is 4G

Now in the VM, I do some cp work. This ends up with copying 1 gig of data.
My space consumption on the Host OS increased by 1G.

Now I delete the data in the Guest VM thus decreasing the space by 1G.

I would like to see the space freed in the Host also. Currently, blocks don't get deallocated upon deletion from the sparse file and thus there are no more holes there.

Filing it here to track as a low-priority Feature Request for RHEL 6
Comment 2 Ric Wheeler 2008-11-13 09:26:02 EST
Ritesh, can you give me some additional details on which file system you are using (I assume that the local fs is ext3).


Comment 3 Ritesh Raj Sarraf 2008-11-13 11:40:13 EST
Yes, Both the guest and the host, are using the ext3 filesystem.
Comment 4 Ric Wheeler 2008-11-13 11:44:51 EST
Are you using a sparse LUN (i.e., you want us to support unmap) or is this simply a request to compact the ext3 file's block allocation at the FS level?

Ext3 does not support cutting out blocks from the middle of a file - you will only reclaim blocks on truncation or unlink.

XFS does have a special ioctl() interface to allow holes to be punched in the middle of its files but you would have to invoke that from your VM layer.

Thanks for the quick reply!
Comment 5 Ritesh Raj Sarraf 2008-11-13 12:41:26 EST
This feature request is for Ext3 file system's block allocation at the FS level.

Since ext3 is the mainstream file system in RHEL products, it'd be good to have this feature.

Without this file system intelligence in place, it'd be difficult Thin Provisioning a virtualized storage environment.

With when the "trim" command is in place, the only additional requirement would be to be able to de-allocate blocks from the middle of a file.
Comment 6 Ric Wheeler 2008-11-13 13:11:49 EST
So there are two distinct features:

(1) support for TRIM/unmap. This is in ext4 upstream, not sure if it made it back to ext3.

(2) support for punching holes in files (i.e., release the middle 1MB in your 1GB file). XFS is the only file system that does this today.

If you have specific interest in (1), it would be great to have access to hardware that implements the T10 unmap commands for netapp. Thanks!.
Comment 8 Ric Wheeler 2009-09-11 13:16:04 EDT
There is high level support for discard in the current upstream kernel, but we still have key patches and some design issues left to flesh out before we can get the full support for either the ATA TRIM or SCSI WRITE_SAME/UNMAP implemented.

Interested storage vendors are encouraged to weigh in on the design and help us validate with their gear.
Comment 9 Chris Ward 2009-11-25 05:09:55 EST

We need to confirm that there is third-party commitment to 
test for the resolution of this request during the RHEL 6.0 
Beta Test Phase before we can approve it for acceptance 
into the release.

In order to avoid any unnecessary delays, please post a 
confirmation as soon as possible, including the contact 
information for testing engineers.

Any additional information about alternative testing variations we 
could use to reproduce this issue in-house would be appreciated.
Comment 10 Ritesh Raj Sarraf 2009-11-25 06:46:40 EST
NetApp is committed to test this feature.

Please let me know which release of RHEL/Fedora will have support for SCSI UNMAP and WRITE SAME.
We can also help test against the development tree also.
Comment 11 Ric Wheeler 2009-11-30 10:16:45 EST
Christoph is our lead on testing this feature.
Comment 12 chellwig@redhat.com 2009-12-11 07:20:24 EST
The feature has now half-landed in mainline.  I will backport it to Fedora and RHEL once the remaining bits have hit the tree in their final form.
Comment 15 Andrius Benokraitis 2010-09-03 18:10:31 EDT
(In reply to comment #10)
> NetApp is committed to test this feature.
> Please let me know which release of RHEL/Fedora will have support for SCSI
> We can also help test against the development tree also.

Has this been tested by NetApp or any other partners?
Comment 20 Ritesh Raj Sarraf 2010-09-08 05:15:13 EDT
(In reply to comment #15)
> Has this been tested by NetApp or any other partners?

Not yet. We'll test the discard feature soon on the kvm hypervisor.
Comment 21 Ronald Pacheco 2010-09-16 19:34:44 EDT

Have you been able to verify this?  If so, please mark it as verified.  Thanks!
Comment 22 Ritesh Raj Sarraf 2010-09-28 15:19:29 EDT
This will take more time. We will test the space reclamation (block de-allocation) of the guest VM files on the host, once we do our KVM testing. That might take some more time.

BTW, will a guest vm with an ext4 file system de-allocate the blocks in the guest ? Will the same also reflect on the host with zeroes in the file ? 

For the other features (Optimal IO Alignment, SCSI CMDs) We are already following on that in other bugzillas.
Comment 23 chellwig@redhat.com 2010-09-29 02:26:47 EDT
There is no support for UNMAP in qemu/kvm in RHEL6 yet.
Comment 25 releng-rhel@redhat.com 2010-11-11 11:02:43 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.