similar to: [PATCH 1/2] v2v: Make fstrim warning clearer (RHBZ#1366456).

On Fri, Aug 12, 2016 at 04:50:31PM +0200, Pino Toscano wrote: > On Friday, 12 August 2016 10:37:29 CEST Richard W.M. Jones wrote: > > 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

On Friday, 12 August 2016 10:37:29 CEST Richard W.M. Jones wrote: > 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

On Friday, 12 August 2016 22:19:09 CEST Richard W.M. Jones wrote: > On Fri, Aug 12, 2016 at 04:50:31PM +0200, Pino Toscano wrote: > > On Friday, 12 August 2016 10:37:29 CEST Richard W.M. Jones wrote: > > > This reverts the change made for RHBZ#1168144. The warning is now > > > always displayed. > > > > > > It would be nice to make the warning

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. --- ...virt-sparsify-in-place-fstrim-unsupported.sh | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git

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

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

This *may* be required by some filesystems in order for fstrim to work. I'm not actually sure if this is true, but it's what virt-sparsify --in-place does, and that utility has been tested a lot more in regards to trimming. --- v2v/v2v.ml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index 8365aae..8ae3dec 100644 --- a/v2v/v2v.ml +++

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

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

Hi, I'm trying to find out how to enable fstrim support for libvirt/qemu guests. Specifically I'm trying to enable this on a CentOS 7 host (qemu 1.5). I searched the web but only found very vague information and no clear documentation on the requirements or how to modify the guest xml to enable discard/fstrim support. Can someone point me in the right direction? Regards, Dennis

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 Mon, Nov 3, 2014 at 4:24 PM, Michal Privoznik <mprivozn@redhat.com> wrote: > On 01.11.2014 05:30, Dennis Jacobfeuerborn wrote: >> >> Hi, >> I'm trying to find out how to enable fstrim support for libvirt/qemu >> guests. Specifically I'm trying to enable this on a CentOS 7 host (qemu >> 1.5). I searched the web but only found very vague information

Because we run the external fstrim command we don't have access to the kernel errno when it fails. However in the case where it prints this specific error message, turn that into errno ENOTSUP. --- daemon/fstrim.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/daemon/fstrim.c b/daemon/fstrim.c index 1ad3630..527acfd 100644 --- a/daemon/fstrim.c +++

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 Friday, 5 August 2016 12:22:45 CEST Richard W.M. Jones wrote: > Because we run the external fstrim command we don't have access to the > kernel errno when it fails. However in the case where it prints this > specific error message, turn that into errno ENOTSUP. > --- Can you please note this behaviour in the documentation of the fstrim API? Thanks, -- Pino Toscano

The first two patches implement the change discussed here: https://www.redhat.com/archives/libguestfs/2016-April/msg00178.html The third patch fixes the mapping of inspection data to OVF VmType which was inherited directly from old virt-v2v and had never been changed. It had a number of problems. The fourth patch is only slightly related to the others. It adds an extra slow test to ensure that

umount_all() and shutdown() are performed by guestfs automatically on close(), so drop explicit calls to them right before close(). Also umount_all() in the middle of processing doesn't look justified so drop it, too. (The only step following it is do_fstrim() which does mounting/umounting on its own). Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 4 ---- 1 file

Hi! With 3.2-rc4 (probably earlier), Ext4 seems to remember what areas it trimmed: merkaba:~> fstrim -v /boot /boot: 224657408 bytes were trimmed merkaba:~> fstrim -v /boot /boot: 0 bytes were trimmed But BTRFS does not: merkaba:~> fstrim -v / /: 4431613952 bytes were trimmed merkaba:~> fstrim -v / /: 4341846016 bytes were trimmed Is it planned to add this feature to BTRFS

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