Fedora Donma Sorunu Çözümü: zram + Disk Swap + earlyoom

Fedora yüklü dizüstümde bir süredir uğraştığım bir sorun vardı: bilgisayarım ağır yük altında tamamen donuyor, hiçbir tuşa yanıt vermiyor, mecburen güç düğmesine basılı tutup kapatmak zorunda kalıyordum. Bu yazıda bu donma sorununu nasıl teşhis ettiğimi ve kalıcı olarak nasıl çözdüğümü, kullandığım komutları tek tek göstererek anlatıyorum. Aynı sorunu yaşayan olursa birebir uygulayabilir.

Sistemim / Test Ortamı#

Önce hangi donanım ve yazılımda çalıştığımı paylaşayım, çünkü çözümün ayrıntıları buna göre değişebiliyor:

Not: Komutların çoğu tüm Fedora sürümlerinde (ve büyük ölçüde diğer Linux dağıtımlarında) çalışır. Ama dosya sistemi btrfs olduğu için swap dosyası oluştururken buna özel bir yöntem kullandım; ext4 kullanıyorsanız o kısım daha basit.

Sorun tam olarak neydi?#

Belirti şuydu: Aynı anda birden fazla ağır uygulama çalıştırdığımda (benim durumumda bir Android ortamı + Android Studio + çok sekmeli tarayıcı + arka planda başka araçlar) sistem önce yavaşlıyor, sonra tamamen kilitleniyordu. Fare bile kıpırdamıyordu. Beklemek çözmüyordu; tek çare güç düğmesiydi.

İlk başta “donanım mı bozuk, ısınma mı var” diye düşündüm. Ama tahmin yürütmek yerine sistemin kendi günlüklerine (log) bakmaya karar verdim — çünkü Linux, donduğu anı zaten oraya yazıyor.

Adım 1: Kök nedeni bulmak (donma anının loglarını okumak)#

Linux, çöktüğü ya da donduğu anı çekirdek günlüklerine yazar. Bir önceki oturumun (yani donduğum oturumun) son satırlarına şöyle baktım:

# Bir önceki açılışın (-b -1) son 40 satırı
sudo journalctl -b -1 -n 40 --no-pager

Bellek tükenmesi (OOM = Out Of Memory) izi olup olmadığını da özel olarak aradım:

# Bir önceki açılışta "oom-killer" tetiklenmiş mi?
sudo journalctl -b -1 --no-pager | grep -iE 'out of memory|oom-kill|killed process'

Çıkan sonuç her şeyi açıkladı. Loglarda şu satırlar vardı:

Free swap  = 148kB
Total swap = 8388604kB
systemd-oomd invoked oom-killer

Yani 8 GB’lık swap alanımın neredeyse tamamı (sadece 148 KB kalmış) dolmuştu ve RAM de bitmişti. Sistem, bellek bulmaya çalışırken kilitlenmişti. Donmanın sebebi donanım değil, bellek yönetimiydi.

Adım 2: Hangi swap’i kullanıyorum? (zram kontrolü)#

Burada işin püf noktası ortaya çıktı. Fedora’nın varsayılan olarak zram kullandığını aslında zaten biliyordum — ama “biliyorum” ile “kontrol edip gördüm” arasında fark var. Hem kendim emin olmak, hem de aynı sorunu yaşayan birinin kendi sisteminde nasıl bakacağını göstermek için her adımı komutuyla anlatıyorum. Peki “8 GB swap” nerede — diskte mi, RAM’de mi? Şu komutla kontrol ettim:

# Aktif swap alanlarını ve türlerini göster
swapon --show

Çıktı şuydu:

NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition   8G ...  100

Yani swap’imin tamamı zram’dı. Peki zram nedir?

zram nedir? RAM’in bir kısmını ayırıp orada sıkıştırılmış bir swap alanı oluşturan bir çekirdek modülüdür. Diske göre çok hızlıdır çünkü fiziksel olarak RAM’dedir. Fedora, 33 sürümünden (2020) beri yeni kurulumlarda swap’i disk yerine varsayılan olarak zram’da oluşturuyor; Fedora 34’te bu alanın boyutu RAM’in yarısına (en fazla 8 GB) çıkarıldı — sistemimdeki 8 GB’lık zram tam da bu varsayılanın sonucu.

zram’ın detayına şu komutla bakabilirsiniz:

# zram cihazının boyutu, algoritması, sıkıştırma oranı
zramctl

İşte sorunun kökü buradaydı: Benim swap’im %100 zram idi, yani RAM’in içindeydi. Diskte hiç swap yoktu. Bu şu demek: RAM dolunca, zram da (o da RAM’de olduğu için) doluyor ve verinin kaçacağı hiçbir yer kalmıyordu. Sistem de bu noktada çakılıyordu.

Sorunun özü buydu: diskte bir emniyet ağı olmadan çalışmak. Diskte swap bulunan bir sistemde RAM dolunca fazlalık diske taşar; sistem yavaşlar ama yaşamaya devam eder, donmaz. Bende ise swap tamamen zram olduğu, yani diskte hiç swap bulunmadığı için o emniyet ağı yoktu.

Çözüm planı#

Araştırınca bunun çok bilinen bir Fedora davranışı olduğunu gördüm. Çözüm için üç katmanlı bir plan kurdum:

1. Diske swap dosyası eklemek — asıl emniyet ağı (Windows’un pagefile’ı gibi).
2. zram’ı biraz büyütmek — hızlı katmanı genişletmek (8 GB → 12 GB).
3. earlyoom kurmak — sistem tamamen donmadan, en obur süreci otomatik kapatan bir koruma.

Mantık şu: RAM dolunca önce hızlı zram kullanılsın, o da dolunca fazlalık diske aksın, en kötü ihtimalde de earlyoom devreye girip sistemi kurtarsın.

Adım 3: Diske swap dosyası eklemek (asıl çözüm)#

Dosya sistemim btrfs olduğu için swap dosyasını rastgele oluşturamıyorsunuz; btrfs, swap dosyasının CoW kapalı (NOCOW), sıkıştırmasız ve deliksiz olmasını şart koşuyor. Neyse ki modern btrfs araçlarında bunu otomatik yapan bir komut var. 16 GB’lık bir swap dosyası oluşturdum:

⚠️ Bu adımı uygulamadan önce okuyun. Aşağıdaki komutlarda bir eksik var: SELinux etiketlemesi. O sırada fark etmedim; iki gün sonra ekranıma SELinux uyarısı olarak çıktı. Komutları o günkü hâliyle bırakıyorum, çünkü gerçekten böyle yapmıştım. Ama siz aynı eksikle uygulamayın: eksiğin ne olduğunu ve bu adımın doğrusunu yazının sonundaki Ek: İki gün sonra karşıma çıkan SELinux uyarısı bölümünde veriyorum. Oradaki komut bloğunu kullanırsanız bu sorunu hiç yaşamazsınız.

# 1) Swap için ayrı bir subvolume (snapshot'lardan izole olsun diye)
sudo btrfs subvolume create /var/swap

# 2) 16 GB swap dosyası — NOCOW/sıkıştırma ayarlarını otomatik yapar
sudo btrfs filesystem mkswapfile --size 16g /var/swap/swapfile

# 3) Swap'i etkinleştir — öncelik 10 (zram'ın 100'ünden DÜŞÜK olmalı)
sudo swapon /var/swap/swapfile --priority 10

Önemli kural — öncelik (priority): Linux’ta yüksek öncelik önce kullanılır. zram’ın önceliği 100. Disk swap’e bilerek 10 verdim ki zram dolmadan diske düşülmesin. Yani hız için önce RAM, emniyet için sonra disk.

Kalıcı olması (her açılışta otomatik gelmesi) için /etc/fstab’a ekledim:

# fstab'a kalıcı satır ekle
echo '/var/swap/swapfile none swap defaults,pri=10 0 0' | sudo tee -a /etc/fstab

Kontrol ettim:

swapon --show

NAME               TYPE      SIZE USED PRIO
/dev/zram0         partition   8G ...  100
/var/swap/swapfile file       16G  0B   10

Artık toplam swap 8 GB’dan 24 GB’a çıkmıştı ve en önemlisi, RAM dolunca gidecek bir disk emniyeti vardı.

ext4 kullanıyorsanız#

Sizin diskiniz btrfs değilse işlem daha basit:

sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile --priority 10
echo '/swapfile none swap defaults,pri=10 0 0' | sudo tee -a /etc/fstab

Adım 4: zram tavanını yükseltmek (8 GB → 12 GB)#

Fedora’nın varsayılan zram ayarı min(ram, 8192), yani 32 GB RAM’im olmasına rağmen zram’ı 8 GB’la sınırlıyordu. Hızlı katmanı biraz genişletmek için bunu 12 GB yaptım:

# zram-generator ayar dosyasını oluştur/güncelle
sudo tee /etc/systemd/zram-generator.conf <<'EOF'
[zram0]
zram-size = min(ram, 12288)
EOF

Bir de açılışta zram modülünün garanti yüklenmesi için şunu ekledim:

echo zram | sudo tee /etc/modules-load.d/zram.conf

Burada bir hata yaptım (dürüst not)#

Bu ayarı, bilgisayarı yeniden başlatmadan hemen devreye almak istedim:

sudo systemctl restart systemd-zram-setup@zram0.service

Ama komut hata verdi. Biraz uğraştıktan sonra sebebini anladım: zram-generator, sistem çalışırken anında değiştirilecek şekilde değil, yalnızca bilgisayar açılırken devreye girecek şekilde tasarlanmış. Boyut değişikliğini uygulamanın temiz yolu ya zram modülünü elle kaldırıp yeniden yüklemek ya da bilgisayarı yeniden başlatmaktı. Ben en temizini seçtim: ayarları yazdım ve yeniden başlatmayı en sona bıraktım. Kısacası her komut ilk denemede çalışmadı; doğrusunu denerken öğrendim.

Adım 5: earlyoom ile son emniyet#

Disk swap donmayı çözer ama ben bir kat daha güvence istedim. earlyoom, bellek kritik seviyeye inmeden en obur süreci otomatik kapatan küçük bir servis:

# earlyoom kur ve açılışta otomatik başlat
sudo dnf install -y earlyoom
sudo systemctl enable --now earlyoom

Fedora’nın hazır ayarlarıyla geliyor ve güzel yanı: kritik sistem süreçlerini (masaüstü, systemd, cryptsetup vb.) asla öldürmüyor, önce tarayıcı sekmeleri gibi büyük ve feda edilebilir süreçleri hedefliyor.

Adım 6: Değişiklikten sonra kontrol (en kritik aşama)#

Ayarları yapmak yetmez; gerçekten uygulandığından emin olmak lazım. Önce sistemi yeniden başlattım, çünkü asıl soru şuydu: “Bu ayarlar açılışta otomatik gelecek mi?”

Yeniden başlattıktan sonra tek komutla baktım:

swapon --show

NAME               TYPE      SIZE USED PRIO
/dev/zram0         partition  12G  0B  100
/var/swap/swapfile file       16G  0B   10

İşte kanıt: zram 12 GB olarak otomatik geldi ve disk swap de aktifti. Toplam 27 GB swap. Koruma servislerini de doğruladım:

systemctl is-active earlyoom systemd-oomd
free -h

Kurulumun doğruluğunu denetlemek#

Paranoyak biri olarak, btrfs swap dosyasının gerçekten kurallara uyduğunu da kontrol ettim. En önemlisi NOCOW bayrağı:

# 'C' harfini görmemiz gerekiyor (btrfs swap için zorunlu)
sudo lsattr /var/swap/swapfile

---------------C------ /var/swap/swapfile

C bayrağı vardı, yani NOCOW doğru ayarlanmış. Aslında en güçlü kanıt şu: btrfs çekirdeği çok katıdır — CoW’lu, sıkıştırılmış ya da delikli bir dosyayı swap olarak açmayı reddeder. Dosya swapon --show çıktısında aktif göründüğüne göre, çekirdek zaten tüm bu denetimlerden geçirmiş demektir.

Sonuç: Artık donmuyor#

Bu üç katmanlı kurulumdan sonra sistem, ağır yük altında donup güç düğmesine basmamı gerektirmek yerine kısa süre yavaşlıyor, sonra kendine geliyor. Özetle yaptığım şey:

• 16 GB disk swap ekledim → RAM dolunca taşma yeri (asıl çözüm).
• zram’ı 12 GB’a çıkardım → daha geniş hızlı katman.
• earlyoom kurdum → son emniyet freni.
• Toplam swap 8 GB → 27 GB oldu ve hepsi kalıcı.

Hızlı kontrol komutları (özet)#

Aynı sorunu yaşıyorsanız, önce durumunuza bakın:

swapon --show      # Swap diskte mi, zram'da mı?
zramctl            # zram detayları
free -h            # RAM ve swap kullanımı
sudo journalctl -b -1 | grep -i oom-kill   # Donma anında OOM var mıydı?

Eğer swap’iniz tamamen zram ise ve diskte hiç swap yoksa, büyük ihtimalle benimle aynı sorunu yaşıyorsunuz. Yukarıdaki adımlar işinizi görecektir.

Ek: İki gün sonra karşıma çıkan SELinux uyarısı (ve etiket meselesi)#

Yazıyı yayınladıktan iki gün sonra bilgisayarı açtığımda ekrana şu uyarı penceresi geldi:

SELinux bir problem tespit etti. Kaynak işlem: systemd-logind Bu erişim denendi: search directory üzerinde: /var/swap

Yani kendi oluşturduğum swap klasörü SELinux’a takılmıştı. Doğrusu bir an “eyvah, swap’i mi bozdum” diye düşündüm. Ama panik yapmak yerine yine aynı yolu izledim: önce kanıt, sonra karar.

Önce: Swap gerçekten bozuldu mu?#

En kritik soru buydu, ilk onu sordum:

swapon --show
free -h

NAME               TYPE      SIZE USED PRIO
/var/swap/swapfile file       16G   0B   10
/dev/zram0         partition  12G   0B  100
---
Swap:           27Gi          0B        27Gi

Rahatladım. Swap çalışıyordu, 27 GB’ın tamamı ayaktaydı. Demek ki uyarı, sistemi bozan bir şey değildi. Bu, işi sakin kafayla incelemem için bana alan açtı.

Sonra: Uyarı tam olarak ne diyor?#

SELinux’un mantığı şudur: her dosyaya bir etiket yapıştırır, sonra “hangi program hangi etiketli dosyaya dokunabilir” kurallarını uygular. Etiketlere baktım:

ls -Zd /var/swap
ls -Z /var/swap/swapfile

?                                          /var/swap
unconfined_u:object_r:unlabeled_t:s0       /var/swap/swapfile

İşte sebep. unlabeled_t = “etiketsiz”. Klasörün etiketi o kadar yoktu ki ls bile ? bastı.

Denetim kayıtlarında da aynı şey yazıyordu:

sudo ausearch -m AVC -ts today

avc: denied { search } for pid=2596 comm="systemd-logind" name="swap"
scontext=system_u:system_r:systemd_logind_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

Cümleyi okumak kolay: systemd-logind (kaynak), unlabeled_t etiketli bir dizine (hedef) search yapmak istedi, reddedildi.

Peki neden etiketsiz kaldı?#

Suçlu bendim — daha doğrusu yukarıdaki Adım 3’te attığım şu komut:

sudo btrfs subvolume create /var/swap

btrfs swap dosyası için ayrı bir subvolume oluşturmuştum (snapshot’lardan izole olsun diye, doğru bir tercihti). Ama elle oluşturulan bir subvolume SELinux etiketi almadan geliyor. SELinux de etiketsiz bir şey görünce ne yapacağını bilemez ve güvenli tarafta kalır: erişimi engeller.

Yani sistemde bozulan bir şey yoktu; klasörün SELinux tarafında bir karşılığı yoktu, o kadar.

Neden zararsız olduğuna karar verdim#

Üç gerekçeyle:

1. Engellenen şey işe yaramaz bir erişimdi. systemd-logind’in /var/swap klasöründe zaten bir işi yok; oraya bakması engellenince hiçbir şey kaybolmuyor.
2. Swap’in kendisi engellenmiyordu. Çekirdek swap dosyasını okuyup yazmaya devam ediyordu — swapon --show bunun kanıtıydı.
3. Uyarı 24 kez tekrarlamıştı ama hepsi aynı açılışa aitti; büyüyen bir sorun değildi.

Yani sistemde çalışmayan bir şey yoktu; SELinux, sonucu hiçbir şeyi etkilemeyen bir erişimi engelleyip beni uyarıyordu. Ama her açılışta ekranın ortasına pencere açan bir uyarıydı bu. Görmezden gelmek yerine sebebini ortadan kaldırmaya karar verdim.

Çözüm: Etiketleri yapıştırmak#

İki komut yetti:

# 1) Kalıcı kural: "bu dosya bir swap dosyasıdır"
sudo semanage fcontext -a -t swapfile_t '/var/swap/swapfile'

# 2) Kuralı uygula (klasöre var_t, dosyaya swapfile_t)
sudo restorecon -Rv /var/swap

Çıktı tam istediğim gibiydi:

Relabeled /var/swap from system_u:object_r:unlabeled_t:s0 to system_u:object_r:var_t:s0
Relabeled /var/swap/swapfile from unconfined_u:object_r:unlabeled_t:s0 to unconfined_u:object_r:swapfile_t:s0

Neden chcon değil de semanage? İnternette bu tür sorunlara sık sık chcon -t ... dosya çözümü öneriliyor ve işe de yarıyor — ama geçici olarak. chcon etiketi sadece o anki dosyaya yapıştırır; politika veritabanına hiçbir şey yazmaz. Sistem bir gün tam yeniden etiketleme yaparsa (restorecon -R / ya da /.autorelabel) chcon’un yaptığı uçar, sorun geri gelir. semanage fcontext ise kuralı politikaya yazar; restorecon da o kuralı okuyup uygular. Yani semanage + restorecon ikilisi kalıcı, chcon yara bandı. Aynı hatayı iki kere yapmamak için doğrusunu tercih ettim.

Doğrulama (yine en kritik aşama)#

Bir ayarı yapmak yetmez; gerçekten uygulandığını görmek gerekir — swap’i kurarken de aynı şekilde ilerlemiştim. Üstelik bu sefer sistemin o an kullandığı bir dosyanın etiketini değiştirmiştim. Swap’e bir zarar geldiyse bunu sonra değil, hemen öğrenmem gerekiyordu.

# 1) Etiketler oturdu mu?
ls -Zd /var/swap ; ls -Z /var/swap/swapfile

# 2) Swap hâlâ ayakta mı? (asıl soru bu)
swapon --show

# 3) Kural kalıcı kaydedildi mi?
sudo semanage fcontext -l -C | grep swap

# 4) Açılışta yine binecek mi?
grep -i swap /etc/fstab

# 5) Yeni bir red oluşuyor mu?
sudo ausearch -m AVC -ts recent | grep -c denied

Sonuçlar sırasıyla:

system_u:object_r:var_t:s0                 /var/swap
unconfined_u:object_r:swapfile_t:s0        /var/swap/swapfile

NAME               TYPE      SIZE USED PRIO
/var/swap/swapfile file       16G   0B   10
/dev/zram0         partition  12G   0B  100

/var/swap/swapfile   all files   system_u:object_r:swapfile_t:s0

/var/swap/swapfile none swap defaults,pri=10 0 0

0

Beşi de temiz: etiketler yerinde, swap’e hiçbir şey olmamış, kural politikaya yazılmış, fstab girdisi duruyor ve yeni red sıfır. Uyarıya sebep olan eksiklik giderildi; o pencere bir daha karşıma çıkmadı.

Bir uyarı: eski kayıtlar listede kalır#

Küçük bir ayrıntı beni bir an yanılttı: sorunu çözdükten sonra bile SETroubleshoot listesinde eski uyarılar duruyordu. Panik yapmayın — onlar geçmişin arşivi, canlı sorun değil. Listeyi görmek için:

sudo sealert -l '*'

Geçmişi tamamen temizlemek isterseniz:

sudo rm /var/lib/setroubleshoot/setroubleshoot_database.xml
sudo systemctl restart setroubleshootd

Bu yalnızca uyarı geçmişini siler; SELinux politikasına ya da denetim kayıtlarına (/var/log/audit/) dokunmaz. Gerçek bir sorun çıkarsa yeni uyarı yine gelir.

SELinux uyarısı aldığınızda ne yapmalı?#

Buradan çıkardığım asıl sonuç şu: “SELinux uyarı verdi” ile “sistem bozuldu” aynı şey değil. İnternette bu tür uyarıları görenlerin ilk refleksi çoğu zaman SELinux’u tamamen kapatmak oluyor (SELINUX=disabled). Bu, yangın alarmı çaldı diye alarmı duvardan sökmeye benziyor: uyarı kesilir, ama sizi koruyan şeyi de kapatmış olursunuz. Üstelik benim durumumda asıl sorun iki komutla çözülüyordu — korumayı kapatmak, çözülebilecek bir sorunu kalıcı hale getirmek olurdu.

Doğrusu şu sırayla ilerlemek:

1. Zarar var mı? Önce onu ölç (swapon --show gibi asıl işlevi kontrol et).
2. Uyarı ne diyor? Kaynağı, hedefi, eylemi oku (ausearch, sealert).
3. Kök neden ne? Benimkinde: elimle oluşturduğum subvolume SELinux etiketi almadan oluşmuştu.
4. Doğru yerden düzelt. Politikaya kalıcı kural yaz; uyarıdan kurtulmak uğruna korumanın tamamını kapatma.
5. Doğrula. Hem sorunun bittiğini hem de hiçbir şeyi bozmadığını.

Bir de şunu not edeyim: btrfs’te elle subvolume oluşturuyorsanız, sonrasında restorecon çalıştırmayı alışkanlık hâline getirin. Bunun neden gerektiğini iki komutla kendiniz görebilirsiniz:

mkdir /tmp/deneme                     # ls -Zd -> etiketi kendiliğinden gelir
btrfs subvolume create /tmp/deneme2   # ls -Zd -> '?' yani ETİKETSİZ

Fark bu kadar basit. Normal bir klasör oluştursaydım etiketini üst klasörden (/var → var_t) otomatik alırdı ve bu uyarıyı hiç görmezdim. Sorun btrfs subvolume create’e özgü.

Adım 3’ün doğrusu: baştan kursaydım böyle yapardım#

Adım 3’te attığım komutları olduğu gibi bıraktım, çünkü gerçekten öyle yapmıştım. Ama bu bölümü okuduğunuza göre artık eksiği biliyorsunuz. Swap’i bugün sıfırdan kursam o adımı şöyle yazardım:

# 1) Swap için ayrı bir subvolume
sudo btrfs subvolume create /var/swap

# 2) SELinux etiket kuralı — swap dosyası OLUŞMADAN ÖNCE yazılmalı ki
#    aşağıdaki restorecon uygulayacak bir kural bulsun
sudo semanage fcontext -a -t swapfile_t '/var/swap/swapfile'

# 3) 16 GB swap dosyası — NOCOW/sıkıştırma ayarlarını otomatik yapar
sudo btrfs filesystem mkswapfile --size 16g /var/swap/swapfile

# 4) Etiketleri uygula (klasöre var_t, dosyaya swapfile_t)
sudo restorecon -Rv /var/swap

# 5) Swap'i etkinleştir — öncelik 10 (zram'ın 100'ünden DÜŞÜK olmalı)
sudo swapon /var/swap/swapfile --priority 10

# 6) Kalıcı olması için fstab satırı
echo '/var/swap/swapfile none swap defaults,pri=10 0 0' | sudo tee -a /etc/fstab

Eklenen tek şey 2. ve 4. satırlar. Sıraları önemli: restorecon, politikada yazan kuralı uygular — kural yoksa uygulayacağı bir şey de olmaz. Bu iki satırla klasör baştan var_t, dosya da swapfile_t etiketini alır; ne SELinux uyarısı çıkar, ne de iki gün sonra bu bölümü okumanız gerekir.

Sonra doğru yaptığınızı iki komutla kontrol edin:

swapon --show                                  # swap gerçekten bindi mi?
ls -Zd /var/swap ; ls -Z /var/swap/swapfile    # etiketler yerine oturdu mu?

Görmeniz gerekenler:

NAME               TYPE      SIZE USED PRIO
/dev/zram0         partition   8G ...  100
/var/swap/swapfile file       16G  0B   10

system_u:object_r:var_t:s0                 /var/swap
unconfined_u:object_r:swapfile_t:s0        /var/swap/swapfile

Swap listede görünüyorsa ve etiketler var_t / swapfile_t ise adım tamamdır: toplam swap 8 GB’dan 24 GB’a çıkmış, diskte emniyet oluşmuş ve benim iki gün sonra karşılaştığım uyarı sizde hiç çıkmayacak durumdadır.

Buradan yazının kaldığı yerden — Adım 4: zram tavanını yükseltmek — devam edebilirsiniz. (zram’ı 12 GB’a çıkarma ve toplamı 27 GB’a taşıma işi orada.)

---

Bu yazı, kendi başımdan geçen gerçek bir sorunu ve uyguladığım çözümü anlatıyor. Buradaki komutlar benim sistemimde işe yaradı, ama her sistem farklıdır. Uygulamadan önce önemli verilerinizi yedekleyin ve komutları kendi sisteminize göre (özellikle dosya sistemi farklıysa) uyarlayın.

Önemli: Yapacağınız tüm işlemler tamamen kendi sorumluluğunuzdadır. Bu adımları uygularken oluşabilecek veri kaybı, sistem arızası veya başka herhangi bir zarardan sorumlu değilim. Bir komutun ne yaptığından emin değilseniz, uygulamadan önce mutlaka araştırın ve elinizde güncel bir yedek olduğundan emin olun.