Thin VMDK: Silinen Alan Datastore’a Neden Geri Dönmez?

Linux sanal makinesinde büyük bir dosyayı silmek, VMDK dosyasının veya storage array üzerindeki kullanılan alanın hemen küçüleceği anlamına gelmez.

İşletim sisteminin boş olarak işaretlediği blokların alt katmanlara TRIM/UNMAP mekanizmasıyla bildirilmesi gerekir.

Üç farklı kapasite

Konuk işletim sisteminde görülen boş disk alanı, thin VMDK'nın tükettiği alan ve VMFS datastore arkasındaki storage tüketimi birbirinden farklı olabilir.

Önce hangi katmanda alan kazanmayı beklediğimizi belirlemeliyiz.

Linux üzerinde kontrol

Disklerin discard yeteneğini ve dosya sistemlerini incelemek için:

lsblk -D
df -hT
findmnt -D

Discard desteği doğrulanmış uygun dosya sistemlerinde bakım penceresinde şu komut kullanılabilir:

sudo fstrim -v /var

Her dosya sistemi veya sanal disk yapılandırması TRIM'i desteklemeyebilir. İşlemin başarılı dönmesi de storage array tarafında aynı miktarda alanın hemen geri kazanıldığı anlamına gelmez.

ESXi üzerinde neleri kontrol etmeliyiz?

• Sanal disk gerçekten thin provisioned mı?
• Disk üzerinde snapshot bulunuyor mu?
• Kullanılan sanal donanım sürümü discard komutlarını destekliyor mu?
• Datastore VMFS5 mi, VMFS6 mı?
• Storage array tarafında UNMAP desteği ve uygun blok granülerliği mevcut mu?

VMFS6 otomatik geri kazanım desteğine sahip olsa da bütün depolama sistemlerinde aynı davranışı garanti etmez.

Yaygın hata

İşletim sistemi içinde silinen dosyaları yalnızca df -h ile kontrol etmek yeterli değildir.

Önce dosya sistemi, ardından VMDK ve son olarak datastore/array üzerindeki tüketim karşılaştırılmalıdır.

Üretimde host seviyesindeki UNMAP işlemleri gelişigüzel çalıştırılmamalıdır. Storage üreticisinin ve Broadcom'un ilgili sürüm belgeleri doğrulanmalıdır.

Kaynak: Broadcom VMFS UNMAP ve Linux guest fstrim sorun giderme belgeleri.