Naplózó filerendszerek (journaling)

Alacsony memóriaigényű linuxos filerendszer

Egy 128 GB-os pendrive-on létrehoztam egyetlen partíciót, majd megformáztam f2fs-re. Bedugtam a kis szappantartó router-embe - 64 MB RAM-ja van - dugott USB hubba, majd megpróbáltam mount-olni. Tulajdonképpen sikerült, csak egy-egy parancsra alig reagált a router, majd kb. két perc elteltével össze is dőlt, nem natolt tovább.

A lényeg, hogy úgy tűnik, az f2fs driver RAM-ban akarta tartani a filerendszer leírókat, valami adminisztrációt, amihez kevés volt a RAM.

Milyen filerendszert válasszak, ami nem eszi meg a RAM-ot, s lehetőleg kíméli az USB mass-storage flash device-t, azaz a pendrive-ot, lehetőleg kezeli a linuxos jogosultságokat, valamint naplózott?

ZFS mozgatás másolás nélkül

Sziasztok,

Kezdő ZFS felhasználóként a következőket tettem: két régi, kisebb HDD-ről egy nagy SSD-re másoltam anyagokat.

Ezt úgy tettem, hogy az ssd_pool/root datasetbe tettem a hdd1 anyagait, a ssd_pool/root/hdd2-be pedig a hdd2 anyagait, hogy miért az már lényegtelen, így sikerült send/recv-elni a régi HDDkról.

A kérdésem, hogy miképpen tudom megszüntetni az ssd_pool/root/hdd2-t, azáltal, hogy a rajta található fájlokat az ssd_pool/root-be szeretném átmozgatni.

Amikor megpróbáltam, akkor észrevettem, hogy ez fizikai másolással jár, amit nem igazán értek, hiszen a mozgatás még ext4-nél is egy gyors művelet volt, csak áttette a bejegyzést egy másik könyvtárba és kész.

Van eset, amikor az egyszerű mv is másolás nélkül megy ZFS-en? Beállításokon, a datasetek elrendezésén múlik? (tekintve, hogy szülő-gyerek módon vannak a datasetek, főleg nem kellene akadály legyen ez..)

Valami más mód amivel tudok másolásmentesen mozgatni? (clone?)

Azért érdekel, mert egyrészt nem szeretném az SSD-t feleslegesen írni, másrészt mi történik, ha nincs annyi szabad hely, hogy egy adott fájl kétszer is elférjen mielőtt törölné az eredetit?

Nekem idáig úgy tűnt, hogy a pool az, ami a fizikai hardverrel van közelebbi kapcsolatban, a datasetek inkább logikai elválasztást jelentenek. De több helyen is azt olvastam, hogy mozgatás szempontjából két dataset az mint két önálló fájlrendszer funkcionál.

Valaki légyszives homályosítson fel! :)

F2FS diszk használat

Most migrálom az adataimat a régi gép SSD-jéről a másikra, és ezt látom az újon:

root@XXX-mobile:/home# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-home--lv      320G  308G   13G  97% /home
root@XXX-mobile:/home# du -sh *
267G    XXX

Ez hogy lehet? Azért a ~40 GB eltérés elég combos. F2FS alatt nincs root-nak fentartott százalék, és amúgy is, root-ként annak nem kéne látszania.

Hogy lehet megtudni fájlok méretét btrfs-en?

Elkezdtem kb. két hete btrfs-t használni a NAS-ban, és ugyan tetszik és elégedett vagyok vele, de hozott magával pár buktatót.

A NAS tartalmáról több kisebb külső hdd-re készítek mentést időnként. Régen ez úgy ment, hogy a NAS-on hardlinkekkel és törléssel csökkentettem a duplikációt, és rsync-kel ment a másolás a backup diszkekre. Mindegyik backup diszkhez tartozott egy rsync parancs, ami néhány könyvtárat átmásolt (és közben figyelt a hardlinkekre).

Btrfs-en a blokk szintű deduplikációt próbálom belőni (még nincs kialakítva a végleges megoldás).

Azt észrevettem, hogy az rsync ezt nem kezeli, így vagy azt csinálom, hogy a backupra dedup nélkül másolok mindent, vagy rsync helyett mást használok. Erre mondta valaki, hogy btrfs send/receive.

send/receive-hez subvolume kell, nem tudok csak random könyvtárakat megadni, mint eddig. Ezzel csak az a gond, hogy subvolume-ok nem osztoznak az inode-okon (ibögökön :-D ), ezért hardlink nem megy mindenen át.

OK, akkor a subvolume-ok kialakítása után, de még az oda tartozó könyvtárak átmásolása előtt lekérdezem, hogy vannak-e olyan hardlinkek, amik ezeken a könyvtárakon kívül vannak, és amiket a mv eltörne. OK, ezeket akkor cp --reflink módon helyettesíteni tudom. Így nem nő meg az eddigi helyfoglalásom.

De most meg abba a problémába futottam bele, hogy 1) a du-nak fogalma sincs arról, hogy fájlok megosztoznak blokkokon, szóval egy reflinkkel másolt fájlt kétszer simán megszámol, és aztán behazudja nekem, hogy pl.

root@bananapi:/srv/dev-disk-by-id-dm-name-nas/gee/to-backup# du -h reflinktest/
316G    reflinktest/

Miközben valójában a könyvtárban ugyanaz az egy darab 158G-s fájl van meg kétszer. Ami egyébként a könyvtáron kívül is megvan. Szóval nekem az lenne jó, ha ezt a könyvtárat kérdezem, akkor 158G-t mondjon, ha meg mondjuk egy könytár struktúrát számolok rekurzívan, akkor ha már egyszer megszámolta ezt a fájlt máshol, akkor ezt a könyvtárat 0-nak vegye.
Ahogy ezt hardlinkek esetén a du ügyesen le is kezeli.

Szóval egyfelől ha valaki tudja, hogy tudom egy fájl, egy könyvtár hierarchia vagy egy subvolume on-disk méretét lekérdezni, annak örülnék.

2) Ha reflinkkel másoltam egy fájlt, nem tudom, hogyan tudom meg róla, hogy osztozik blokkokon más fájlokkal - és ha igen, melyik fájlokkal. Illetve nem tudom, hogy van-e egyáltalán ilyen funkció, remélem, hogy igen.

Erre tud valaki megoldást?

Illetve ha van ötletetek, hogy lehetne ezt jobban, hatékonyabban vagy egyszerűbben csinálni, az is jöhet.

Egyelőre most ott tartok, hogy dobom az egész subvolume és btrfs send/receive koncepciót, mert sokat kell pl. az eltört hardlinkek egyenkénti kézzel helyettesítésével vacakolni, és akkor még jön a többi; megtartom, ami eddig volt, hardlinkek és rsync csak néhány könyvtárra, és ugyan a NAS-on lesz blokk szintű deduplikálás, a biztonsági másolatoknál nem, csak a hardlinkek lesznek, mert csak rsync-kel másolok. Így továbbra is tudom a du-t használni és látom előre, hogy belefér-e a kisebb backup hdd-re az, amit oda akarok másolni. Cserébe kb. 1TB-tal több tárhely kell a backup diszkeken, mint amennyit a NAS foglal majd a dedup után. :-(

[DUPLÁN MEGOLDVA] [C/C++] ZFS + VPS + Ext4 = Corrupted InnoDB

Két dolog miatt szánok egy kis szösszenetet a sztorinak.

Az egyik oka, hogy igencsak meglepődtem, hogy ilyen meg tud történni a másik oka, mert készült is rá egy megoldás melyet örömmel szeretnék megosztani a közösséggel.

Nagy vonalakban a sztori, hogy egy ZFS storage -el ellátott VPS (KVM alapú) anyagépen, egy tucat Linux VPS -ből az egyik, ext4 fájlrendszere egyik pillanatról a másikra eldobta magát.

ZFS checksum ON, hiba nincs.
ext4 naplózott, nem volt hirtelen halál, ac loss, igazából nagyjából ilyen féléves uptime -ját ünnepelte maga a VPS, 1,5 évvel ezelőtt volt bővítve a fájlrendszer, amúgy Virt-IO.

A történet sajnálatos eredménye, hogy az innoDB .ibd fájlait szépen elkorruptálta, tehát I/O Error -t írt ha másolni, megnyitni akartam, éppen ezért a mySQL vagy el sem indult, vagy nagyon rövid időn belül "felakasztotta magát".

Szóval én láttam már sok mindent, de ilyet nem, mármint VPS esetén:

[23563.216403] blk_update_request: I/O error, dev vda, sector 960227912
[23563.356236] blk_update_request: I/O error, dev vda, sector 960227912
[23563.527275] blk_update_request: I/O error, dev vda, sector 960227912
[23563.805136] blk_update_request: I/O error, dev vda, sector 960227912
[23564.244561] blk_update_request: I/O error, dev vda, sector 960227912
[23564.375360] blk_update_request: I/O error, dev vda, sector 960227912
[23567.440755] blk_update_request: 12 callbacks suppressed
[23567.440781] blk_update_request: I/O error, dev vda, sector 960227912
[23567.520537] blk_update_request: I/O error, dev vda, sector 960227912
[23567.587946] blk_update_request: I/O error, dev vda, sector 960227912
[23568.054547] blk_update_request: I/O error, dev vda, sector 960227912
[23568.075419] blk_update_request: I/O error, dev vda, sector 960227912
[23568.077621] blk_update_request: I/O error, dev vda, sector 960227912
[23568.078390] blk_update_request: I/O error, dev vda, sector 960227912
[23568.079057] blk_update_request: I/O error, dev vda, sector 960227912
[23568.080408] blk_update_request: I/O error, dev vda, sector 960227912
[23568.081079] blk_update_request: I/O error, dev vda, sector 960227912
[23572.441857] blk_update_request: 7307 callbacks suppressed
[23572.441881] blk_update_request: I/O error, dev vda, sector 960227920
[23572.443353] blk_update_request: I/O error, dev vda, sector 960227920
[23572.444023] blk_update_request: I/O error, dev vda, sector 960227920
[23572.444575] blk_update_request: I/O error, dev vda, sector 960227920
[23572.445979] blk_update_request: I/O error, dev vda, sector 96022792

Tehát mégegyszer az "underlaying storage" (ZFS) rendben van, a diszkek is.
qemu-img check nem talált hibát, fsck force lefutott rendben.
qemu-nbd -vel felcsatoltam anyagépen, ott se volt hiba, egészen addig míg nem léptem bele egy "badsector" -ba.

Na erre mondjon valaki okosat nekem.

A másik oldala a dolognak, hogy ám az adatbázis rohadtúl kellett és nem találtam az interneten olyan programot amivel kimondottan csak 1-1 fájlt, helyre lehessen állítani gyorsan és az sem baj ha véres marad, illetve minimálisan testreszabható legyen a visszaállítás, ezért készítettem egyet és a helyzet az, hogy megmentette a napot.

Az ötlet onnan született, hogy van egy fájl ami 500MB, 384MB -nál I/O Error -t dob... Gondoltam, hogy most maximum 512KB -ot nem tud kiolvasni, de a többi részét meglehetne menteni, csak hogy I/O errornál minden belefut az END_OF_FILE -ba és hibával kilép, én meg maradtam egy 384MB -os fájlal amit biztos nem fog megenni a mySQL.

Ami megoldást találtam az a dd és a ddrescue volt, 

dd if=./file1 of=./file1.fix bs=512 conv=noerror,sync iflag=fullblock 

De ezzel az volt a probléma, hogy kellett egy olyan feature is, hogy ne 0x00 -val írja ki a hiányzó részeket, mert pont bekavar az innoDB -nek és nem igazán találtam megfelelő dokumentációt ennek a működéséről és rengeteg helyen kinullázott dolgokat.

Aztán született egy saját megoldás, ami ezt megoldja azzal, hogy ugyanúgy továbblépteti és a hiányzó adatokat tetszőleges karakterrel helyettesíti, és bájtonként halad a recovery része így viszont kaptam egy ugyanakkora méretű fájlt mint az eredeti, csak 1-1 helyen pár kilobájt éppenséggel killett nullázva vagy pont más karakterrel lett behelyettesítve, a visszaállítás sebessége is felülmúlta az alternatívákat.

Ennek köszönhetően, elindult az adatbázis, viszont ahogy belefutott a problémás részbe, "Buffer overflow" -al meg is döglött, létezik egy varázstrükk, ez pedig az `innodb_recovery_mode`, ezt 6 -osra állítva simán adott egy mysqldumpot, ráadásul úgy, hogy egy bájt adat nem hiányzott.

Ja és ECC RAM meg modern környezet.

A program végezetül ami mentett egy nagyott, szó szerint.
https://github.com/DaVieS007/Partial-File-Recovery

 

BTRFS kezdő subvolume kérdés

Egy másik topicban felmerült ez, és most kérdéseim vannak.

A felállás ez: Van egy NAS, benne egy nagyobbacska hdd, btrfs.

Van több kisebb hdd, amikre szeretnék a NAS-on tárolt adatokból backupot készíteni.

Ahogy olvasom, ha készítek egy snapshotot a NAS-on, akkor utána egy btrfs-send --full paranccsal mindent át tudok küldeni egy másik btrfs fájlrendszerre. Remélem, ezt eddig jól értem.

Viszont úgy tűnik, hogy ez a teljes subvolume-ot vinné át és nincs mód arra, hogy mondjuk csak adott könyvtárakat másoljak.

Ha jól sejtem, erre az lenne a megoldás, hogy létrehozok subvolume-okat, a jelenlegi könyvtárakat beléjük mozgatom és így a külön backupolni kívánt könyvtárak külön subvolume-ban lennének.

Ahogy olvasom, minden subvolume-nak külön inode tere lesz, szóval az eddig használt hardlinkekkel vigyáznom kell.

Van valami más, amire oda kell figyelnem?

Ki foglalja a mit foglal a hol foglalja? - Nem létező fájl létező ballaszt üzemmódban

Adott egy kiszolgalo, fejlesztestamogatasra hasznaljuk, a kovetkezot jatssza:

135G szabad hely tegnaprol mara elfogyott (aszongya, hogy nincs u"r az eszkozon), tehat a df szerint elfogyott a hely; du szerint a foglaltsag osszesen (rekurzivan) konstans 25G korul van, magyarul valami fog egy(?) fajlt es veszettul irja, de nem sikerul megallapitani, mi. Tipikusan hasonlot a $TMPDIR vagy valamelyik !syslog altal hasznalt log directory eseten tapasztaltam - ezek jol behatarolhato processzek voltak - ; de jo lenne, ha sikerulne megallapitani, ilyenkor mi fogja a melyik filedescriptort.

Van arra valami hasznalhato tool, hogy megallapitsam, mik az elhagyott file-k, amik mikozben latszolag nem leteznek, folyamatosan hiznak, majd reboot utan visszaall a normalis foglaltsag az erintett (donto reszben/jelenleg ext4) fajlrendszerben?

Remelem, ertelmesen meg tudtam fogalmazni, mit szeretnek elerni. :D

Koszi! :)

udisks2 automount ro

Sziasztok!

Adott:

  • RPi 4B+ 8GB
  • Raspbian Lite (Buster)

Erre telepítve egyebek mellett:

  • . Kodi Leia
  • . udisks2

kodi-standalone indulásakor szépen felmountolja a rádugott USB eszközöket (vinyók) az udisks2 által.
De akármit csinálok, mindig rw lesz az összes mount.

Próbálkoztam:

  • /etc/udisks2/udisks2.conf
  • /etc/udisks2/mount_options.conf

[defaults]
defaults=ro
allow=noexec,ro,...

Hiába veszem ki allow-ból is az rw-t, mégis rw lesz minden mount.
Tudom, hogy udev rules-ban felül lehetne bírálni, de érdekel, hogy az udisks miért disrespecteli a konfigomat.

Mit rontok el?
 

Mivel egyébként sincs szükség rw hozzáférésre (ha mégis, akkor ssh-n remountolom), így igyekszem elejét venni a fájlrendszer korrumpálódásának, ha pl. valaki umount nélkül kihúzza.

Arra van mód, hogy az ro-ként mountolt eszköz kihúzásakor az udisks2 felismerje mi történt és eltakarítsa a romokat? (adjon egy lazy umount-ot mondjuk, hogy kikerüljön az eszköz a mount táblából).

EXT4 -> BTRFS migráció

Otthona konfigom Fedora31 külön /boot, /boot/efi, /, és /home partíciókkal EXT4-ekkel.
BTRFS-ről pedig azt olvastam, még korábban, hogy elég lesz 1 BTRFS partíció mindenre és ez - the way it  meant to be played.
OK.
Majd egy évvel később újratelepítéssel frissítem a Fedora 33-at.
EXT4 esetén formáznám a /boot és / partíciókat, de mi a scenario BTRFSsel?