similar to: [PATCH] sparsify: Fix test-virt-sparsify-in-place-fstrim-unsupported.sh

This addresses the feedback on v1 here: https://www.redhat.com/archives/libguestfs/2018-September/msg00023.html Rich.

Since Linux commit f663b5b38fff trimming vfat is now supported by Linux. This broke the test which assumed it was not supported. Use another filesystem (minix) which does not support trimming instead. Thanks: Daniel P. Berrangé and Pino Toscano. --- ...est-virt-sparsify-in-place-fstrim-unsupported.sh | 13 ++++++------- tests/test-functions.sh | 10 ++++++++++ 2

Here's a fun one: + guestfish -N test-virt-sparsify-in-place-fstrim-unsupported.img=fs:vfat exit + virt-sparsify --in-place test-virt-sparsify-in-place-fstrim-unsupported.img + tee test-virt-sparsify-in-place-fstrim-unsupported.log [ 2.4] Trimming /dev/sda1 [ 7.5] Sparsify in-place operation completed with no errors + grep 'warning:.*fstrim'

On Wed, Sep 05, 2018 at 04:41:01PM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 05, 2018 at 04:37:05PM +0100, Richard W.M. Jones wrote: > > > > Here's a fun one: > > > > + guestfish -N test-virt-sparsify-in-place-fstrim-unsupported.img=fs:vfat exit > > + virt-sparsify --in-place test-virt-sparsify-in-place-fstrim-unsupported.img > > + tee

On Wed, Sep 05, 2018 at 04:53:03PM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 05, 2018 at 04:45:51PM +0100, Richard W.M. Jones wrote: > > On Wed, Sep 05, 2018 at 04:41:01PM +0100, Daniel P. Berrangé wrote: > > > On Wed, Sep 05, 2018 at 04:37:05PM +0100, Richard W.M. Jones wrote: > > > > > > > > Here's a fun one: > > > > > > >

Fix for https://bugzilla.redhat.com/show_bug.cgi?id=1364347

[Let's discuss this upstream] On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote: > I'm missing something here - what will happen to the tree structure? > Will we lose it? So essentially it performs a merge? In copying mode: virt-sparsify disk1 disk2 creates an overlay on top of disk1, writes zeroes to the overlay in the parts of disk1 which are not used (disk1 is not

On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > [Let's discuss this upstream] > > On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote: > > I'm missing something here - what will happen to the tree structure? > > Will we lose it? So essentially it performs a merge? > > In copying mode: > > virt-sparsify disk1

This reverts the change made for RHBZ#1168144. The warning is now always displayed. It would be nice to make the warning actionable, but there is not a lot that end users can do since fstrim is such a complex topic interacting with all filesystem and storage layers. --- v2v/v2v.ml | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index

Hi! This question emerged during testing of oVirt sparsify integration. oVirt now is able to run virt-sparsify on VM disks. But virt-sparsify seems to have no effect on iSCSI disks. Does virt-sparsify work on iSCSI disks? Maybe in sum situation, with some configuration of iSCSI server, with some specific virt-sparsify options? Shmuel

As the minimum block size to discard in qcow2 is 64K, any point in fstrimming smaller contiguous blocks? TIA, Y.

On Wed, Sep 05, 2018 at 04:37:05PM +0100, Richard W.M. Jones wrote: > > Here's a fun one: > > + guestfish -N test-virt-sparsify-in-place-fstrim-unsupported.img=fs:vfat exit > + virt-sparsify --in-place test-virt-sparsify-in-place-fstrim-unsupported.img > + tee test-virt-sparsify-in-place-fstrim-unsupported.log > [ 2.4] Trimming /dev/sda1 > [ 7.5] Sparsify in-place

On Wed, Sep 05, 2018 at 04:45:51PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 05, 2018 at 04:41:01PM +0100, Daniel P. Berrangé wrote: > > On Wed, Sep 05, 2018 at 04:37:05PM +0100, Richard W.M. Jones wrote: > > > > > > Here's a fun one: > > > > > > + guestfish -N test-virt-sparsify-in-place-fstrim-unsupported.img=fs:vfat exit > > > +

zerofree is a package that can take an ext2 (only?) filesystem, work out what parts of the filesystem are not used, and either zero them or sparsify them. This was useful in about 2009 when I added it to Fedora. However nowadays it's more convenient to use the equivalent kernel functionality (via the ‘fstrim’ command or equivalent ioctls). The kernel functionality also works correctly for

Assuming the VM is not running, and we have a base (raw, sparse) with a snapshot (qcow2) on top of it. Is there any issue with running virt-sparsify on the base image? I assume deleted blocks in the base can be sparsified, since they are either still deleted on the snap (which is fine) or were written in the snap (which is fine either and does not change or matter for the base image). Can I assume

This patch is easier to read if you use the 'git show -w' option. Also observe that: fun a -> ( fun () -> (* code *) ) (ie. returning a closure) is identical to: fun a () -> (* code *) Rich.

I think I found a bug affecting btrfs filesystems and users invoking fstrim to discard unused blocks: if I execute a `fstrim -v /` twice, the amount trimmed does not change on the 2nd invocation AND it takes just as long as the first.  Why do I think this is a bug?  When I do the same on an ext4 partition I get different behavior: the output shows 0 B trimmed and it does is instantaneously when I

On Wed, Nov 04, 2015 at 01:10:04PM +0200, Yaniv Kaul wrote: > On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <rjones@redhat.com> > wrote: > > All that happened was that the overlay got bigger (because it's now > > storing a bunch of qcow2 zero clusters marking the places in the > > backing file which are zero). ^^^ Here I should

I still get the "the discard operation is not supported" fstrim error when the LVs are set to "nopassdown" Seems that when I use ext4 the fstrim reports that it worked but the LVs Data% does not decrease after the fstrim. xfs just throws the error. I've also been looking at the output of lsblk -D # lsblk -D NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO xvdb

Hi All I'm trying to setup my LVM thin pool to support discards so that the pool can reclaim space even if the underlying device doesn't support trim. It is my understanding that all thin pools should support trim even if the underlying device doesn't. (please correct me if I'm wrong here) I have one centos server that does support trim and everything is working correctly but any