Rejtélyes tárhelyproblémák – avagy a disk és a kernel viszonya

Az utóbbi néhány napban a szerverem lévő root partíción – ami egy 60G ssd – hirtelen a foglalt terület felkúszott átlag 55%-ról fokozatosan 100%-ig, 0b szabad, a rendszer megáll és nem értem mi történt.

Az első kör

du -sh * / --exclude <azon könyvtárak, melyekbe a diskek vannak felcsatolva>

Nem találtam semmi érdekeset. De szabad hely fokozatosan elfogyott és megszűnt.

Akkor újraindítjuk a rendszert hátha egyszerűen nincs szinkronban a disk foglalt területe a rendszer által “tudottakkal”. Tehát feltételeztem azt, hogy a rendszer valamit csinált (lehet frissítés vagy programhiba), televerte a disk-et, majd leállt, a hely felszabadult (tehát nem megszámlálható, nem látható), csak erről a kernel maga már/még nem tud.

Szóval újraindítottam. Hely ugyanúgy nincs, a szolgáltatások bő fele már el sem indult.

Töröltem a logokat, még mindig ugyanaz a helyzet. Letiltottam néhány service-t amire gyanakodtam, hogy problémázhatnak, majd újraindítottam ismét a gépet. Lett hely ismét, hurrá! Nem világos miért, de hurrá. Amúgy itt követtem el már a második bakimat.

Eltelt egy nap, majd figyelem a muninon, hogy az elmúlt napokban folyamatosan egy fűrészfog mintát sikerült rajzolni a >szépen lassan megtelik a tárhely, majd törlök valamit és újra lesz hely< alapon. És meglátom, hogy ismét ugyanabban a mértékben foly a hely.

Hogy kiderítsem mi okozza a balhét kicsit utánnakutattam és láttam példát, hogy du-t hogyan lehet hatékonyabban használni – konkrétan sorbarendezés, total számítás.

Ebből megszületett ez, amit a / helyen futtatok:

 du -sch * --exclude home --exclude disks | sort -h

És itt szembesültem vele, hogy az apache2 egy nap alatt kb 11G-nyi error.log-ot termel. Botok rátévedtek a szerveremre ahol folyamatosan olyan hívást csinálnak ami php hibát okoz ezért a hibajelentés oda bekerül.

Mit rontottam el?

Először is nem sorrendeztem így elsiklott a szemem felett a du által számolt terület kb/GB eloszlása és nem vettem elsőre észre, hogy az apache2 okozza a balhét.

Második. Ha töröltem a /var/log-ot korábban miért nem szabadult fel a hely? Az alkalmazás az access.log-ot és az error.log-ot nyitva tartja. Valami rejtélyes oknál fogva engedi az OS, hogy töröljem az appendelt fájl-t, de ennek ellenére továbbra is írja azt a kernel, tehát nincs felszabadult terület. Szerinte. Mert hogy még a fájl valószínűleg nyitva marad.

Egy egyszerű

systemctl restart apache2

után újra megjelent 55% foglalt terület és mindenki boldog.

Most már csak a php hibát kell kiküszöbölni, hogy ne legyen tele az apache error log ezekkel. 🙂

DJI + Huawei P20 Pro + Sony vegas – fix

Egy ideje felfigyeltem rá, hogy a DJI go app – ami egy elég jól sikerült darab, pacsi a fejlesztőknek, elég jól lehet használni, ha van egy osmo mobile-od – hajlamos elrontani a felvételt.

Ez abban nyilvánul meg, hogy visszanézve google photos-ra felszinkronizálva minden rendben, VLC, wmplayer is rendben játsza ellenben a Sony Vegas 15 importáláskor a fájlt elrontja/rosszul olvassa be/whatever. Ekkor a kép vagy akadozik vagy hiányzik eleje vagy vége, vagy – és ami a leggyakoribb – a kép a hangtól el-el csúszik.

Ami valljuk be rendkívül bosszantó.

Viszont ahelyett, hogy tovább hőbörögnénk és követelnénk vissza a pénzünket járjunk utána, hogy mit lehet e jelenség ellen tenni.

Lényeg, hogy kell egy ffmpeg és mondjuk egy linuxos bash és az alábbi script-et a fájlok helyén lefuttatjuk:

mkdir fixed;
for i in *.mp4 ; do
    ffmpeg -i $i -preset slow -strict experimental -c:a aac -b:a 192k -codec:v libx264 -pix_fmt yuv420p -b:v 11000k -minrate 11000k -maxrate 14000k -bufsize 14000k -vf scale=-1:1080 fixed/$i.mp4
done

Ez 1080p30 esetén – 4K vagy 1080p60 esetén valszeg magasabb bitrátát kell beállítanod – a fájl tulajdonságai között megtalálod a megfelelő értékeket!

Ekkor készül egy fixed nevezetű mappa és feldolgozás után ott fognak sorakozni a tökéletesen használható nyersanyagok 🙂

Btw ha nincs bash-ed windowson varázsolj egyet rá, vagy írd meg ennek a Windowsos változatát (ami végigiterál a mappa mp4-es elemein) és küldd el nekem és update-elem a postot 🙂

HDD to SSD linuxon

A hétvégén rákényszerültem, hogy a nagyobb méretű, de már régi HDD-ről a linuxos gépemet átköltöztessem egy kisebb méretű SSD-re. A clonezilla nem segített így kézzel kellett átmigrálnom a teljes fájlrendszert.

Halál egyszerű, csak oda kell minden lépésre figyelni.

Teendők:

Rakd be a hdd-t és az ssd-t is egy számítógépbe, lehetőleg sata csatlakozóra kösd, usb-n sokáig fog másolni.

Bootolj be egy live ubuntut a számítógépen.

Ezután nyiss egy konzolt, formázd le a cél ssd-t,

fdisk /dev/sdb #sdb az SSD!
> o
> n
> enter, enter, enter...
> p (ha egy partíció látszik szuper)
> w

mkfs.ext4 /dev/sdb1 #feltéve, hogy ext4-et szeretnél

Készítsük elő a műveleteket

mkdir /mnt/{ssd,hdd}
mount /dev/sda1 /mnt/hdd #sda a HDD!

majd rsync-el másold át, illetve hozd létre a szükséges mappákat

rsync --exclude="mnt" --exclude="lost+found" --exclude="sys" --exclude="proc" --exclude="cdrom" --exclude="media" --exclude="swapfile" -aP /mnt/hdd/ /mnt/ssd/
mkdir /mnt/ssd/{mnt,proc,sys}

Majd telepíts grub-ot

mount -o bind /dev /mnt/ssd/dev
mount -o bind /sys /mnt/ssd/sys
mount -t proc /proc /mnt/ssd/proc
cp /proc/mounts /mnt/ssd/etc/mtab
chroot /mnt/ssd /bin/bash
grub-install /dev/sdb
grub-install --recheck /dev/sdb
update-grub

Majd írd át a bootolandó meghajtó uuid-ját az fstab-ban

blkid /dev/sdb1

Az itt található uuid-t vidd fel az fstab-ba

nano /mnt/ssd/etc/fstab

Ha nem kaptál sehol hibát

init 0

A gép leáll, vedd ki a hdd-t, kapcsold vissza, biosban csekkold le, hogy az ssd-ről fog-e bootolni.

Enjoy!

Digionline servlet Kodi-hoz

Az ittott.tv-s servletem után itt az újabb készítmény, mellyel egyszerűvé válik a tévézés Kodin.

Tehát ez egy servlet, illetve lejátszótól független kiegészítő ami a hivatalos http://onlineplayer.digi.hu weboldalon elérhető tv csatornák megnyitását teszi lehetővé külső alkalmazások számára.

Szükséges hozzá már meglévő digionline hozzáférés, melyet abban az esetben regisztrálhatsz a digi ügyfélkapuján keresztül, ha rendelkezel kábeltévé és internet előfizetéssel is. E program működéséhez nem szükséges digi hálózat, de legjobb tudomásom szerint csak magyar ip címről működik.

 

Egy előfizetéshez jelenleg max három digionline account regisztrálható, a servlet egyszerre csak egy accountot kezel, így egyidőben egy servlet egyetlen lejátszót képes kiszolgálni.

E program indításakor legenerál egy m3u és egy xml fájlt – az előbbiben a teljes csatornalista az utóbbiban 5 napra elölre elektronikus programujság (EPG) található, melyet képes lejátszani a VLC, de teljes műsorújsággal együtt a KODI is.

Kodi-n az IPTV Simple Client-et kell beállítani, majd bekapcsolni – miután a servlet elindult a háttérben megnyithatóvá válnak a digionline rendszerében elérhető csatornák HD minőségben.

Részletek, leírás, telepítés:

https://github.com/szabbenjamin/digionline

 

SSD cache linux rendszeren

Képzeld el – van egy méretes HDD-d, melyen adatbázist tárolsz, torrentezel, vagy oprendszert futtatsz. Végülis mindegy, a lényeg az, hogy néha marha lassú a rendszer, IOwait a plafonban.

Tudod jól, hogy kéne ssd-re váltani, de nincs az a pénz, hogy marha nagy HDD-k helyett SSD-kre cseréljél.

Szóval a probléma adott, HDD kéne megközelítőleg SSD tempóban – vajon mi lehet a megoldás?

Mintapélda, teljesítményben egy idális világot képez :)
Mintapélda, teljesítményben egy idális világot képez 🙂

Egy korábbi részben ecseteltem egy lehetséges megoldást erre vonatkozóan Windows rendszeren, de most nálam linux szerveren adódott a probléma és a dolog megoldásért kiáltott és végül találtam valamit.

bcache

Az elv itt is azon alapul, hogy a merevlemez írási és olvasási gyorsítótárát kiegészíti a rendszerhez illesztett plusz SSD.

Nekem egy 3T-os disk-em van és úgy alakult, hogy egy 60G SSD felhasználható a célra. Mindkét meghajtót a leggyorsabb sata portokra csatlakoztattam és az alábbiakat műveltem.

Törölnöm kellett a teljes ssd-t és a gyorsítani kívánt partíciót (sde = SSD, sdc = HDD):

wipefs -a /dev/sde

wipefs -a /dev/sdc1

Létrehoztam egy bcache partíciót:

make-bcache -C /dev/sde -B /dev/sdc1 --block 4k --discard --writeback

Írási gyorsítótártól ha tartasz ne használd a writeback paramétert, ha pedig az ssd-d nem támogatja a TRIM módot vedd ki a discard paramétert.

Ezután már csak létrehoztam az új tömbön egy fájlrendszert:

mkfs.ext4 /dev/bcache0

Majd /etc/fstab-ba felvettem a /dev/bcache0 virtuális meghajtót és voila.

Statisztikákért pedig ezekhez nyúlok:

cat /sys/block/bcache0/bcache/dirty_data

tail /sys/block/bcache0/bcache/stats_total/*

Vagy akár folyamatosan:

watch -n 5 tail /sys/block/bcache0/bcache/stats_total/*

 

Jó kísérletezést! 🙂