XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Delta Backups & Continous Replication of Empty Drives

    Scheduled Pinned Locked Moved Xen Orchestra
    14 Posts 3 Posters 1.1k Views 1 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S Offline
      stevewest15 @stevewest15
      last edited by stevewest15

      @olivierlambert Thanks for your help:

      • xo-server 5.70.0

      • xo-web 5.74.0

      • XCP-ng 8.0

      1 Reply Last reply Reply Quote 0
      • olivierlambertO Offline
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by

        Check the size of the VHD on the SR itself. I think it might be because the VHD hasn't freed blocks on the filesystem.

        1 Reply Last reply Reply Quote 0
        • S Offline
          stevewest15
          last edited by stevewest15

          EDIT: @olivierlambert Thank you, I checked the SR and it's showing much larger size (421 GB) while the VM OS shows only 1.3 GB:

          root@freenas25[/mnt/Tank/VMs]# du -hs 6e07202c-38f0-dece-52d6-d81743635645/55a93b7d-1e2e-4903-961b-c3df8b73fee3
          .vhd
          421G    6e07202c-38f0-dece-52d6-d81743635645/55a93b7d-1e2e-4903-961b-c3df8b73fee3.vhd
          

          VM OS

          [root@server420 ~]# du -hs /Backups/
          1.3G    /Backups/
          
          nraynaudN 1 Reply Last reply Reply Quote 0
          • olivierlambertO Offline
            olivierlambert Vates 🪐 Co-Founder CEO
            last edited by

            Ping @julien-f

            1 Reply Last reply Reply Quote 0
            • S Offline
              stevewest15
              last edited by

              Hi @olivierlambert , sorry the VHD path I provided above was wrong.

              It appears the SR is showing it's using 421 GB while the VM OS shows 1.4 GB.

              How long does it take for "VHD to free blocks on the filesystem"? This is NFS SR.

              Thx,

              SW

              1 Reply Last reply Reply Quote 0
              • olivierlambertO Offline
                olivierlambert Vates 🪐 Co-Founder CEO
                last edited by

                So it's logical then. XOA is just pulling all the VHD blocks exposed by the host.

                What you can do: try to reclaim on the VM FS (eg trim? I don't remember, maybe @nraynaud knows more).

                Alternatively, you can use xe vdi-copy to create a new cleaner VHD with only what's used.

                1 Reply Last reply Reply Quote 0
                • nraynaudN Offline
                  nraynaud XCP-ng Team @stevewest15
                  last edited by

                  @stevewest15 Hello, can you tell us the list of partitions and what FS are inside the VHD please?

                  thanks,

                  Nicolas.

                  nraynaudN 1 Reply Last reply Reply Quote 0
                  • nraynaudN Offline
                    nraynaud XCP-ng Team @nraynaud
                    last edited by

                    Here are a few of the operations I have in mind:
                    https://unix.stackexchange.com/questions/44234/clear-unused-space-with-zeros-ext3-ext4

                    1 Reply Last reply Reply Quote 0
                    • S Offline
                      stevewest15
                      last edited by

                      @nraynaud Hi, Thank you for your assistance. Here is /etc/fstab from the VM which is CentOS 7.x:

                      UUID=ef4eef1c-dea6-452e-9fb4-20948465f484 /boot                xfs    defaults        0 0
                      /dev/mapper/centos-root /                                      xfs    defaults        0 0
                      /dev/xvdh1  /emails                                            xfs    defaults        0 0
                      /dev/mapper/databases-var_lib /var/lib                         xfs    defaults        0 0
                      /dev/mapper/sas10k-var_log /var/log                            xfs    defaults        0 0
                      /dev/mapper/websites-var_www /var/www                          xfs    defaults        0 0
                      /dev/mapper/centos-swap swap                                   swap   defaults        0 0
                      
                      UUID=20706a6e-bda3-4277-abf1-c74c4619a1d8 /Backups/      xfs    defaults        0 0
                      

                      And this is from XO:
                      f3b14e07-82bd-470f-9bbb-0001be7dfe6d-image.png

                      nraynaudN 1 Reply Last reply Reply Quote 0
                      • nraynaudN Offline
                        nraynaud XCP-ng Team @stevewest15
                        last edited by

                        @stevewest15 Thanks, I'm not really familiar with XFS. there might be a way to reclaim (trim) or zero the unused place on the disk.

                        1 Reply Last reply Reply Quote 0
                        • olivierlambertO Offline
                          olivierlambert Vates 🪐 Co-Founder CEO
                          last edited by

                          It should: xfs.org/index.php/FITRIM/discard

                          A fstrim /mountpoint should work.

                          1 Reply Last reply Reply Quote 0
                          • S Offline
                            stevewest15
                            last edited by stevewest15

                            @olivierlambert Thanks, I tried running fstrim but it returned "the discard operation is not supported" on this NFS SR mount. I also tried running on SSD mounts which do support TRIM and they all returned the same message about "discard...not supported."

                            The VM OS (CentOS 7.8) does support TRIM in kernel so not sure if xcp-ng or xenserver is the reason why the VM can't issue fstrim on the NFS SR mount or the SSD SR mounts.

                            85b94dd0-b129-45ec-9ee2-bc4b7dd92b5e-image.png

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post