Bug 471356

Ritesh, can you give me some additional details on which file system you are using (I assume that the local fs is ext3).

Regards,

Ric

Yes, Both the guest and the host, are using the ext3 filesystem.

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!

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.

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!.

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.

@Reporters

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.

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.

Christoph is our lead on testing this feature.

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.

(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
> UNMAP and WRITE SAME.
> We can also help test against the development tree also.

Has this been tested by NetApp or any other partners?

(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.

Ritesh,

Have you been able to verify this?  If so, please mark it as verified.  Thanks!

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.

There is no support for UNMAP in qemu/kvm in RHEL6 yet.

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.