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. :-(
Hozzászólások
Az ls -i parancs megmondja az inode-ot. Az ls -l második oszlopa pedig szerintem az, hogy hányan hivatkoznak rá, bár nem tudom biztosan. Szerintem lehet ebből valamiféle adatbázist építeni, és ha egyszer már volt az inode, akkor másodjára nem számolod be a méretet. Meg sokadjára sem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A második oszlop a hardlinkek száma, hogy pontosak legyünk (amit mondasz, jó, csak esetleg a kérdezőnek infó). :)
Igen, csak a hard link meg az eredeti file név nem különbözik tudtommal. Ha létrehozom file1-et, ez a szám 1. Ha erre csinálok file2 névvel egy hard linket, akkor ez a szám 2. Ha törlöm file1-et, ez a szám megint 1, s egyedül file2 hivatkozással tudom elérni a file-t. Ha ezt is törlöm, a számláló eléri a nullát, ekkor az egész file helye felszabadításra kerül, azaz törlődik.
Arra gondoltam, hogy ahol ez a szám 1-nél nagyobb, csak azokban az esetekben kell a kérdéssel foglalkozni, ami gyorsítja az algoritmust, nem kell minden esetben inode szerint keresni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Teljesen egyetértek, ahogy írtam, csak a kérdezőnek akartam plusz infót adni esetlegesen. :)
egyetlen kiegeszites itt annyi, hogy a file torlese nem torli az adatot csak az inode tabla bejegyzest, az adat ott marad a blockokban, majd ha kell valaminek felul lesznek irva. Ezert is konnyu torolt allomanyt visszaallitani ha meg nem tortent iras a filerednszerre azota (torles utan rogton mount -o remount,ro :D)
Egyetértek, és ezért is fogalmaztam így:
Nem törlődik, csak a nyilvántartásból kerül kifűzésre.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszönöm a segítő szándékot, de a hardlinkekkel nincs gond, a du ügyesen csak egyszer számolja meg az egy inode-hoz tartozó fájlokat.
A gondom a cp --reflink módon másolt fájlokkal van, amik külön inode-hoz tartoznak ugyan de a diszken ugyanazok az adatblokkok tartoznak mindegyik fájlhoz (amíg el nem kezdek néhány blokkot felülírni, mert akkor már lesznek közös és eltérő blokkok is lesznek a lemezen).
Meg persze cp helyett máshogy is el lehet érni ezt az állapotot.
Szóval az a bajom, hogy míg a hardlinknél egyértelmű, reflinkelt fájlokról nem látom ugyanezt ugyanígy és azt se tudom, hány adatblokk közös.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Ezt a reflinket nem ismertem. Ha jól értem, ez azt csinálja, hogy amíg ugyanaz a két file, addig ugyanazokból a blokkokból áll, így csak egyszer foglal helyet, ha változik, akkor viszont a változott rész más blokkba kerül. Ügyes, de ezt tényleg nem triviális megszámolni így.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen, ezt csinálja.
Tényleg ügyes.
És egy hete még én se ismertem :-)
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
1.) btrfs filesystem du -s könyvtár
2.) btrfs filesystem du fájl
Azt, hogy mikkel osztozik, azt nem tudom, hogyan lehet megállapítani.
De hát pont ezt írtam, hogy ez nem működik.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Átolvastam újra, de nem láttam, hogy írtad volna.
Csak a sima du parancsot láttam, ami valóban nem így működik.
Pl.:
Akkor lehet, hogy én nézek be valamit. Köszi, majd a hétvégén utánaolvasok.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
2.) A
btrfs inspect-internal dump-tree device
paranccsal lehetne valahogy kinyerni.
De hisz btrfs-en nem kell hardlinkezned a deduplikáció elkerülése érdekben. Csak a deduplikációt kell bekapcsolnod (alapból nincs bekacsolva!!!), és azt is lehetőleg a fájlrendszer létrehozásakor. Vagyis lehet utána is bekapcsolni, de akkor csak a bekapcsolás után létrehozott fájlokat fogja csak érinteni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
A hardlinkek még a btrfs előttről származnak.
Hmm. És ezt hogyan? Én csak olyan megoldást találtam, amit offline deduplikációnak hívnak és valami daemon fut, nézegeti időnként a fájlokat és ha duplikációt talál akkor azt eliminálja. Ezek szerint valamit valahol nem vettem észre?
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.