Search results for query: shrink

Thank you brother , this helped so much

Please don't quote every message. You can simply shrink the volume as your partition was not resized yet. I'm always scared about rounding issues so I'd account for that with a bit of a buffer. I.e partition size + 1G. In your case this is not needed and should be safe. Shut down the VM, remove...

Wohoo! The shrink-operation (crosspost for details) has completed, stats are returning, backup is running, and I'm winding down.

One way is to restore the backup via the CLi and give a specific size for the rootfs like this. Another way is to lie to the system by editing the size in the config file before creating the backup and then restoring it. As for the lock I'd try something like pkill fstrim and pct unlock 104. I...

I didn't read all of it but you can shrink thin volumes, just not the thin pool itself. Here's some outputs from when I demonstrated this to someone # lvresize -r -L 8G pve/vm-101-disk-0 File system ext4 found on pve/vm-101-disk-0. File system size (20.00 GiB) is larger than the requested...

Update, unexpected failure at step 1, While logged in to the host, with the container shut down, I resized the FS in the LV to 600 GB: # fsck.ext4 /dev/mapper/allerlei-vm--104--disk--0 e2fsck 1.47.0 (5-Feb-2023) /dev/mapper/allerlei-vm--104--disk--0: clean, 5198085/244908032 files...

...want to extract the disk that backs the thin volume out of the system running Proxmox, but run into the issue that thin volumes don't support shrinking. After moving stuff out of the way, there is a lot of air in the container, but the thin volume is, of course, still the original size. Some...

...to use the SSD for the OS and fast VMs, and the HDDs for slow VMs and backups. Should I re-do my RAID as RAID1 + RAID10? Or should I try to shrink the local-lvm? Also, an AI suggested creating a "Backup VM" inside local-lvm and mounting it back—is that actually a thing people do in the real...

...resize and manage your disk partitions before starting the cloning process. Since you only have 19G of data, you can use GParted within the Rescuezilla environment to shrink the source partition first, and then proceed with the clone. It might be a more straightforward solution for your needs.

Kannst Du bitte endlich aufhören hier jeden Tag hier Kistenweise AI Slop abzuladen. Langsam geht mir das wirklich auf den Keks. Ich dachte Du verstehst den Wink mit dem Zaunpfahl aber irgendwo ist auch mal Feierabend.

...Belegung steigt weiter): Falls kurzfristig Luft geschaffen werden muss und VMs mit ungenutzten/überdimensionierten Disks existieren — qemu-img convert einer qcow2 auf sich selbst (shrink) oder gezieltes Aufräumen innerhalb der VMs wären Sofortmaßnahmen, die unabhängig vom UNMAP-Problem wirken.

...yourself if it gets full. defiant-local refers to the pve VG but as mentioned all its space is already allocated to root and swap so you can't use that. With your current setup you can only really use local. You can technically shrink root and then re-create data but you need to live boot for...

I was looking for a process and tried this. Clonezilla gives a warning that it cannot be used to clone a larger disk to a smaller one. I tried anyhow and it say disk was out of space. 19G on a 70G disk trying to move to a 25G disk. No go.

You can limit ARC: https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_limit_memory_usage (While the ARC has the capability to shrink on demand, this mechanism is often to slow for a sudden request --> OOM)

For my part this explains everything. It's not implemented on the NetApp side yet. And NFS 4.2 is need afaik. https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-Issues/CONTAP-178914

...preallocatio=metadata and preallocation=off. Both yield the same result as above. In no case whatsoever am I able to get the vmdisk.qcow2 to shrink it's size after it have grown. The only thing that works is to do a storage migration to another volume, this shrinks it back to what is actually...

...steps and set it up with SSD emulation=off; however, I did not get the same result. Steps 1–8: .qcow grows +5GB Steps 9–10: .qcow does not shrink Steps 11–14: .qcow does not shrink Steps 15–18: .qcow grows with an additional +5GB Steps 19–21: .qcow does not shrink Power cycling after this...

Okay that make sense thank you. Now I know what to look into further.

The default stripe_unit size for ceph is 4M, but you may not want to raise that (and maybe even shrink it instead.) the stripe size is a maximum "file chunk" limit for a cephfs object (file). if a file is larger than the stripe size, the next portion of the file is written to A DIFFERENT PG...

...are still roughly 150GB in size... I assume that it is because when a thin virtual disk has used the space once, the virtual disk does not shrink back down automatically. But is there something I can do to easily shrink it? That would save me both backup space, bandwidth and give room for...