VDS Diskimi Büyüttüm Ama Görünmüyor: growpart ve resize2fs ile Çözüm

Paneli açtınız, sunucunuzun diskini 40 GB'tan 80 GB'a yükselttiniz, ödemesini yaptınız, hatta emin olmak için makineyi yeniden başlattınız. SSH ile bağlanıp df -h yazıyorsunuz ve karşınızda hâlâ aynı satır duruyor: /dev/vda1 39G 37G 1.5G 97% /. Ne yeni alan var, ne bir hata mesajı. Sistem, sanki hiçbir şey olmamış gibi çalışmaya devam ediyor ve disk dolmak üzere.

Bu bir arıza değil ve sağlayıcınız işini yapmamış da değil. Linux'ta disk alanı üç ayrı katmandan geçer ve hipervizör bunlardan yalnızca en alttakini büyütür. Kalan iki katmanı — bölüm tablosunu ve dosya sistemini — sizin büyütmeniz gerekir. Bu bilinçli bir tasarım tercihidir: işletim sistemi, altındaki blok cihazın büyüdüğünü fark ettiğinde kendi kendine bölüm tablosuna dokunmaz, çünkü o tabloda sizin bilmediği başka planlarınız olabilir.

Bu yazıda LVM kullanmayan, tek bölümlü tipik VDS imajını merkeze alıyorum — Ubuntu, Debian, Rocky ve AlmaLinux'un standart bulut imajlarında karşınıza çıkan yapı budur. Önce lsblk ile durumu doğru okumayı, sonra growpart ile bölümü ve resize2fs veya xfs_growfs ile dosya sistemini büyütmeyi göreceğiz. Yanlış disk ya da yanlış bölüm numarası seçmenin ne anlama geldiğini ve işleme başlamadan önce neden anlık görüntü almanız gerektiğini de baştan konuşacağız.

Diski Büyüttünüz Ama df Neden Değişmiyor#

Sunucunuzdaki depolama, üst üste binmiş üç katmandan oluşur. Her katmanın kendi boyut kavramı vardır ve biri büyüdüğünde diğerleri otomatik olarak takip etmez:

Panelden yaptığınız işlem yalnızca birinci satırı değiştirir. İkinci satırdaki bölüm hâlâ "40 GB'lık bir diskin 39 GB'ını kaplıyorum" diye kayıtlıdır; üçüncü satırdaki dosya sistemi de bölümün sınırlarına saygı duyduğu için 39 GB olarak kalır. df -h size üçüncü katmanı gösterir, bu yüzden hiçbir değişiklik görmezsiniz.

Bazı bulut imajları bu adımları açılışta kendiliğinden yapar: cloud-init paketinin growpart ve resize_rootfs modülleri tam olarak bunun için vardır ve etkinse yeniden başlatma sonrası disk büyümüş olarak gelir. Yeniden başlattığınız hâlde bir değişiklik yoksa, imajınızda bu modüller kapalı ya da paket kurulu değil demektir. Elle yapacağız.

Başlamadan Önce: Anlık Görüntü ve Doğru Diski Seçmek#

Bu işlem, çalışan bir sistemin bölüm tablosunu yeniden yazar. growpart bunu güvenli yapmak için tasarlanmıştır ve verinin başladığı sektöre dokunmaz, ama yanlış disk veya yanlış bölüm numarası verirseniz başka bir bölümün alanına yazmış olursunuz ve o veriyi geri getirmenin pratik bir yolu yoktur.

İki kural işi neredeyse risksiz hâle getirir:

1. İşlemden önce anlık görüntü (snapshot) alın. Sağlayıcınızın panelinde bu seçenek varsa kullanın; birkaç saniye sürer. Anlık görüntü ile yedek aynı şey değildir — aradaki farkı snapshot mı yedek mi yazısında ele aldık — ama bu iş için doğru araç anlık görüntüdür, çünkü tek amacı birkaç dakikalık bir işlemi geri alabilmektir.
2. Komutu yazmadan önce lsblk çıktısına bakın ve okuduğunuzu doğrulayın. Aşağıdaki bölüm tam olarak bunu anlatıyor.

Disk zaten %100 doluysa ve sistem hata vermeye başladıysa, önce birkaç yüz megabaytlık nefes alanı açmanız gerekebilir: disk dolu no space left çözümü yazısındaki hızlı temizlik adımları bu iş için yeterlidir.

lsblk Çıktısını Okumak: Neyin Büyümesi Gerektiği#

Her şeyden önce mevcut durumu görün:

lsblk

Tipik bir çıktı şöyle görünür:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda    252:0    0   80G  0 disk
├─vda1 252:1    0   39G  0 part /
├─vda14 252:14  0    4M  0 part
└─vda15 252:15  0  106M  0 part /boot/efi

Bu çıktı size aradığınız her şeyi söylüyor:

• vda satırı 80G gösteriyor: hipervizör işini yapmış, disk gerçekten büyümüş.
• vda1 satırı 39G ve mount noktası /: kök bölüm bu ve henüz büyümemiş.
• Aradaki ~41 GB şu anda ayrılmamış alan olarak duruyor ve hiçbir bölüme ait değil.

Buradan çıkaracağınız iki değer var: disk adı (vda) ve bölüm numarası (1). growpart komutuna bu ikisini ayrı ayrı vereceksiniz.

Dosya sistemi tipini de öğrenmeniz gerekiyor, çünkü son adımdaki komut buna göre değişir:

lsblk -f
# veya sadece bağlı dosya sistemleri için:
df -hT

FSTYPE sütununda ext4 mi yoksa xfs mi yazdığına bakın. Ubuntu ve Debian imajları çoğunlukla ext4, Rocky ve AlmaLinux ise varsayılan olarak XFS ile gelir. İkisi arasındaki davranış farkları için ext4 ve XFS karşılaştırması yazısına bakabilirsiniz.

Bir isimlendirme notu: disk nvme0n1 gibi görünüyorsa bölümü nvme0n1p1 olur — araya bir p girer. Buna karşılık vda diskinin bölümü vda1, sda diskininki sda1'dir. Bu ayrım komut yazarken sık hata kaynağıdır.

growpart ile Bölümü Büyütmek#

growpart, cloud-utils projesinin bir parçasıdır ve çoğu minimal kurulumda önceden yüklü değildir. Dağıtımınıza göre kurun:

# Ubuntu / Debian
apt update && apt install -y cloud-guest-utils gdisk

# Rocky Linux / AlmaLinux / RHEL
dnf install -y cloud-utils-growpart gdisk

gdisk paketini de kuruyoruz çünkü growpart GPT bölüm tablolarında bazı sürümlerde sgdisk aracına ihtiyaç duyar; kurulu olması hiçbir zarar vermez.

Şimdi en kritik nokta geliyor. growpart komutu disk adını ve bölüm numarasını iki ayrı argüman olarak alır:

# DOĞRU — disk ve numara arasında boşluk var
growpart /dev/vda 1

# YANLIŞ — bu bir bölümü değil, cihazı büyütmeye çalışır ve hata verir
growpart /dev/vda1

Bu ayrım fdisk ve parted alışkanlığı olanları sık yanıltır. Emin olmak için önce kuru çalıştırma yapın; hiçbir şeye dokunmadan ne yapacağını söyler:

growpart --dry-run /dev/vda 1

Beklediğiniz sonucu veriyorsa gerçek komutu çalıştırın:

growpart /dev/vda 1

Başarılı çıktı şuna benzer:

CHANGED: partition=1 start=2048 old: size=81784832 end=81786879 new: size=167688159 end=167690206

start değerinin değişmediğine dikkat edin — bölümün başlangıcı aynı kalır, sadece sonu ileri taşınır. Verinize bu yüzden dokunulmaz.

Çekirdek yeni bölüm tablosunu her zaman anında görmez. growpart bunu genellikle kendisi tetikler, ama lsblk hâlâ eski boyutu gösteriyorsa:

partx -u /dev/vda
# veya
partprobe /dev/vda

lsblk artık vda1 satırında 80G'a yakın bir değer göstermeli. Göstermiyorsa devam etmeyin; sorunu bir sonraki bölümdeki tabloya göre teşhis edin.

resize2fs ve xfs_growfs: Dosya Sistemini Büyütmek#

Bölüm büyüdü ama df -h hâlâ eski değeri gösteriyor, çünkü dosya sistemi kendi sınırlarını hâlâ eski bölüme göre biliyor. Son adım dosya sistemine "artık daha fazla yerin var" demektir ve her ikisi de sistem çalışırken, bağlı durumdayken yapılabilir; yeniden başlatmaya gerek yoktur.

Argüman farkı burada gerçek bir tuzaktır: resize2fs cihaz yolu ister, xfs_growfs ise bağlama noktası. Karıştırırsanız komut hata verir.

ext4 için:

resize2fs /dev/vda1

XFS için:

xfs_growfs /

Btrfs için:

btrfs filesystem resize max /

Şimdi doğrulama:

df -hT /

Yeni boyutu görüyorsanız iş bitmiştir. Toplam alanın panelde yazandan biraz küçük görünmesi normaldir: ext4 varsayılan olarak alanın bir kısmını yalnızca root kullanıcısına ayırır ve üreticilerin GB tanımı ile işletim sisteminin GiB tanımı arasında yaklaşık %7'lik bir fark vardır. 80 GB'lık bir disk df çıktısında 78 GiB civarı görünür.

Hata Aldınız: Mesaj Ne Anlama Geliyor#

En sık karşılaşılan çıktılar ve nedenleri:

Son satır özellikle GPT disklerde görülür. GPT, bölüm tablosunun bir kopyasını diskin en sonunda tutar; disk büyüyünce bu kopya artık sonda kalmaz ve araçlar uyarı verir. parted ile düzeltmek saniyeler sürer ve veriye dokunmaz.

Bir de şu var: kök bölümde resize2fs çalışmıyor ve "device is busy" benzeri bir hata alıyorsanız, muhtemelen dosya sistemi ext4 değil ya da bölüm numarasını yanlış vermişsinizdir. ext4 kök bölümü çalışan sistemde büyütmek desteklenen bir işlemdir ve normalde sorun çıkarmaz.

Bölüm Diskin Sonunda Değilse Ne Olur#

growpart bir bölümü yalnızca arkasındaki boş alana doğru büyütebilir. Bölüm tablonuzda kök bölümden sonra başka bir bölüm varsa — klasik örneği araya konmuş bir takas (swap) bölümüdür — yeni alan kök bölüme bitişik olmadığı için growpart hiçbir şey yapamaz ve NOCHANGE döner.

vda    80G disk
├─vda1 39G part /
└─vda2  2G part [SWAP]      <- kök bölümün önünü kesiyor

Üç seçeneğiniz var:

1. Takas bölümünü kaldırıp yeniden oluşturun. swapoff -a, ardından bölümü silip kökü büyütmek ve sonda yeni bir takas alanı açmak. Bu, bölüm tablosuna elle müdahale gerektirir ve bu yazının en riskli senaryosudur; adımlar için fdisk ve parted ile bölümleme yazısına bakın ve anlık görüntü almadan girişmeyin.
2. Takas bölümünü dosyaya taşıyın. Takas alanını bir bölüm yerine /swapfile dosyası olarak kullanmak modern sistemlerde tamamen normaldir ve bölüm tablosunu sadeleştirir.
3. Yeni alanı ayrı bir bölüm olarak kullanın. Kök bölümü hiç ellemeden yeni alanda ikinci bir bölüm açıp /var/lib/mysql veya /home gibi bir dizine bağlayabilirsiniz. En güvenli yol budur; kalıcı bağlama için mount ve fstab yazısındaki UUID tabanlı yöntemi kullanın.

Üçüncü seçenek çoğu üretim sunucusunda tercih edilmesi gereken yaklaşımdır: çalışan bir sistemin bölüm tablosunu yeniden düzenlemek, kazanılan esneklikle karşılaştırıldığında gereksiz bir risktir.

LVM Kullanıyorsanız Zincir Bir Adım Uzar#

Sisteminizde LVM varsa lsblk çıktısında bölümün altında ubuntu--vg-ubuntu--lv gibi ek bir katman görürsünüz. Bu durumda zincir dört halkalıdır ve arada fiziksel birimi (PV) ve mantıksal birimi (LV) büyütmek gerekir:

# 1) Bölümü büyüt (aynı adım)
growpart /dev/vda 3

# 2) Fiziksel birime yeni alanı tanıt
pvresize /dev/vda3

# 3) Mantıksal birimi tüm boş alana genişlet ve dosya sistemini birlikte büyüt
lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Buradaki -r bayrağı işi kolaylaştırır: lvextend mantıksal birimi büyüttükten sonra dosya sisteminin büyütme komutunu kendisi çağırır, yani ayrıca resize2fs çalıştırmanıza gerek kalmaz. LVM'in katman mantığı ve anlık görüntü yetenekleri için LVM mantıksal birim yönetimi yazısı ayrıntılı bir giriş sunuyor.

İşlem Sonrası Doğrulama ve Temizlik#

İşi bitirmeden önce üç kontrol yapın:

# 1) Katmanların hepsi aynı boyutu mu gösteriyor?
lsblk
df -hT /

# 2) Bağlama tanımları bozulmamış mı? (UUID değişmez ama teyit iyidir)
findmnt --verify
blkid /dev/vda1

# 3) Alan gerçekten kullanılabilir mi?
touch /root/test && rm /root/test

findmnt --verify komutu /etc/fstab dosyasındaki tanımları sınar ve bir tutarsızlık varsa yeniden başlatmadan önce size söyler. Bu, disk işlemlerinden sonra atlanmaması gereken bir alışkanlıktır: hatalı bir fstab satırı, sunucunun bir sonraki açılışta acil kurtarma kabuğuna düşmesine yol açar.

Tüm Adımlar Tek Bakışta#

Standart senaryoyu — tek bölümlü, LVM'siz, ext4 kök dosya sistemi — baştan sona uygulayan sıra şudur. Her satırın çıktısını okuyup bir sonrakine geçin; körlemesine art arda çalıştırmayın:

lsblk                        # 1. Disk büyümüş mü, bölüm hangi numarada?
lsblk -f                     # 2. Dosya sistemi ext4 mü XFS mi?
growpart --dry-run /dev/vda 1  # 3. Ne yapacağını önce söylesin
growpart /dev/vda 1          # 4. Bölümü büyüt
lsblk                        # 5. Bölüm gerçekten büyüdü mü?
resize2fs /dev/vda1          # 6. Dosya sistemini büyüt (XFS ise: xfs_growfs /)
df -hT /                     # 7. Sonucu doğrula

Üçüncü ve beşinci satırlar isteğe bağlı görünür ama işin güvenlik ağı tam olarak onlardır: beşinci adımda bölümün büyümediğini görürseniz altıncı adımı çalıştırmanın hiçbir anlamı yoktur ve nedenini yukarıdaki hata tablosundan bulabilirsiniz.

Son olarak, alan neden dolmuştu sorusunu cevaplamadan işi bitmiş saymayın. Diski büyütmek zaman kazandırır ama kontrolsüz büyüyen bir günlük dosyası ya da temizlenmeyen bir yedek dizini birkaç hafta içinde aynı noktaya getirir. Alanı kimin tükettiğini bulmak için df, du ve ncdu kullanımı yazısındaki yöntemler, dosya sayısı kaynaklı doluluk için de disk kotası ve inode yazısı yol gösterir.

Sıkça Sorulan Sorular#

Bu işlemler için sunucuyu kapatmam gerekir mi?#

Hayır. Hem growpart hem de resize2fs ve xfs_growfs, kök bölüm bağlıyken ve sistem çalışırken kullanılabilir; servisleriniz kesintisiz devam eder. Yeniden başlatma yalnızca çekirdek yeni bölüm tablosunu okumayı reddederse gerekir ve bu, partx -u komutundan sonra nadiren yaşanır. Hipervizör tarafındaki disk büyütme işlemi ise sağlayıcıya göre kapalı makine gerektirebilir.

resize2fs çalıştırdım ama df hâlâ eski boyutu gösteriyor, neden?#

Büyük olasılıkla bölüm adımı atlanmıştır. resize2fs dosya sistemini yalnızca bulunduğu bölümün sınırına kadar büyütebilir; bölüm hâlâ 39 GB ise dosya sistemi de 39 GB kalır ve komut sessizce "zaten bu boyutta" der. lsblk çıktısında disk ve bölüm satırlarının boyutlarını karşılaştırın; farklıysa önce growpart çalıştırmanız gerekir.

Diski küçültebilir miyim?#

XFS'te kesinlikle hayır — bu dosya sistemi küçültmeyi hiç desteklemez, tek yol yedekten yeni ve küçük bir dosya sistemine geri yüklemektir. ext4 küçültmeyi destekler ama yalnızca dosya sistemi bağlı değilken, yani kök bölüm için kurtarma ortamından açılmayı gerektirir. Sanal sunucularda küçültme işlemi genellikle sağlayıcı tarafında da desteklenmez; büyütme tek yönlü bir işlemdir.

Yanlış bölüm numarası verirsem ne olur?#

growpart verdiğiniz bölümü arkasındaki boş alana doğru genişletmeye çalışır. Arkasında başka bir bölüm varsa çoğu durumda NOCHANGE döner ve hiçbir şey yapmaz. Ancak boş alan varsa gerçekten o bölümü büyütür ve yanlış bölümün dosya sistemi bozulabilir. Bu yüzden komutu her zaman önce --dry-run ile çalıştırın ve işleme başlamadan anlık görüntü alın.

df ile panelde yazan boyut neden farklı?#

İki sebep birleşiyor. Birincisi birim farkı: sağlayıcılar genelde 1 GB'ı 1.000.000.000 bayt sayar, df ise 1 GiB'ı 1.073.741.824 bayt kabul eder; bu tek başına yaklaşık %7 fark yaratır. İkincisi ext4'ün varsayılan olarak alanın küçük bir bölümünü sistem süreçleri için ayırmasıdır. Bu ikisi birleşince 80 GB'lık bir disk df -h çıktısında 77-78 GiB civarında görünür ve bu normaldir.

Aynı işlemi ikinci bir veri diski için de yapabilir miyim?#

Evet, adımlar birebir aynıdır; tek fark disk adıdır. Örneğin /dev/vdb diskinin birinci bölümü için growpart /dev/vdb 1 ve ardından dosya sistemine göre resize2fs /dev/vdb1 veya xfs_growfs /mnt/veri çalıştırırsınız. Veri diskini kök bölümden ayrı tutmak, bu tür bakımları çok daha az riskli hâle getirdiği için tercih edilmesi gereken bir düzendir.