Helyzet: van 1 csomó (mondjuk 10+) ilyenolyan diszk, random sokéves tartalommal, valszeg zilliárd duplikációval.
Ötlet: írok 1 vmi szkriptet, h sorban bedugdosom a diszkeket egy olyan gépbe, ami az adott fs-t gond nélkül tudja olvasni, végigmászatom a releváns részeken (foldereken), megjegyzek minden FS nyújtotta metaadatot, mintát veszek a fájlokból (hogy hogyan az 1 másik kérdés), elrakom azt is a meta közé. Mondjuk az igazán fontos tartalomról (pl. JPG, DV, MOV, ilyesmi, ami nyilván pont értékes privát tartalomnak tűnik) abból a neki megfelelő eszközzel fájltípus specifikus metaadatot is kiszedünk.
Kérdés: a dolognak multi OS-nek kell lennie, minimum van macOS HPFS-valamivel, meg NTFS is biztos van, meg extN- linux is biztos, szóval kell 1 megoldás, amivel ezt a sok metaadatot egy helyre kotrom.
Megoldás:git-re gondoltam, minden gép, ahol futtatom ezt a xart nyit 1 új branch-t mondjuk, oda lerak 1-M json-t a metaadatokkal, a végén össze lehet fésülni mindent. Így tudna futni a dolog térben és időben is párhuzamosan. Mondjuk 1előre nincs B terv, ha nincs gihub v net, élmégy a áram v bármi egyéb kvázi vis major.
MAJD, ha lesz rendes sztorázs, akkor oda összehúzni mindent 1x majd. Vagy kiszórni az űrbe a sok felesleges zajt. Vagy nemtudom. Rég álmodok már ilyesmiről és nem feltétlenül szépeket :)
A megoldás részhez kapcsolódó vélemények érdekelnének, szívesen veszem a egyéb ötleteket is.
Hozzászólások
Veszel 1 darab 16-18-20TB-os diszket (nem írtad valójában mennyi az összkapacitás, ezért csak tippeltem). Erre szépen mindent rámásolsz, és ott tartalom alapján megkeresed az egyezéseket. A duplikáltakat meg törlöd pl.
az alap problémát nem értem, hogy miért baj, ha valami rendelkezésre áll több példányban is, különböző adathordozókon (főleg ha Igazán Fontos)
azt az elméletileg lehetséges választ gyorsan elhessegettem, hogy az időd kevesebbet ér, mint a diszkeken duplikátumok által elfoglalt tárterület ára
Én ezt egy "rendet rakok" projektnek gondolom.
Ami kell, összeszedem a "sokmindenről", ha megvan, kiírom több példányban.
Gondolom...
mert pl. az 1ikkel dolgozol, holnapután már senki se tudja, h melyik az origin. és azt se tudjuk, h mi hol van, hogy hol mi van. Lazán kapcs: https://napirajz.hu/itt-mogottem/
Biztos vannak penzes megoldasok erre, de korulbelul mind ugy mukodik ahogy leirtad. Fogja es vegigfesukli az osszes adatot, megcsinalja a metat beloluk, meg a hash-t, aztan megjeloli azokat az adatokat amiknek a hash-e azonos, majd te el tudod donteni a meta alapjan mi kell es mi nem (pl. keep latest and delete others with the same hash).
Vagy ott vannak az objectstore megoldasok amik kicsit mashogy csinaljak ugye a deuplikaciot, ha van ugyanolyan block a kulonbozo adatokban, akkor is csak egyszer taroljak (persze nem, mert azert repolikaljak az adott blockot, hogy szet legyen maszatolba az adat), de a metaadatban ott lesz, hogy melyik file-okhoz tartozik hozza az adott adatblock.
A kerdes hogy mit akarsz? Torolni vagy csak az adat mennyiseget csikkenteni?
másra használni a sok kotvány diszket, pl. bedobálni a házi esxi-be és nemtudom. A dedup kvázi másodlagos, de a 20 éves képekről is kéne tudni, hogy hol lehetnek, stb.
A fő kérdés a több helyről származó metaadat tárolására vonatkozik leginkább.
Hat erre pont ott vannak a noSQL db-k, de akar egy postgres is elviszi. Azert mennek noSQL-el, mert egy kep mas metaadatokat tartalmazhat mint egy video, de igy mehet az egesz egybe, majd a keresesnel megmondod hogy videot vagy kepet keresel e. Ha raeresztesz valami kepfelismero algoritmust is ami megtageli, akkor meg meg olyanra is kereshetsz hogy "eifel tower summer" aztan kidobja az osszes kepet, videot xls-t :D
persze hogy nosql, de kicsit túlzásnak gondolom
Mi a tulzas benne? A noSQL kb nullarol skalazodik a vegtelen fele, szoval kezdheted nagyon minimalban es kicsiben. Raadasul kb. mindenre van mindengyikhez library, igy pillanatok alatt utod ossze a scrapert akarmiben, ami telerakja a metaadatokkal. Egy egynode-s akarmi is kiszolgalja az ennyi metaadatot.
De egy mini postgresql is elviszi. Miben talalod jobbnak, hogy sok-sok branch-en tarolod az adatot GIT-ben? Az analizis fele abban nem lesz meg, mig a noSQL, SQL eseten alapbol a rendelkezesedre fog allni.
Ahogy en latom, a scrape-ert mindenkeppen meg kell irnod, a kerdes az output-ja es annak tarolasi modja + a tarolas utani analizis. Ha az output JSON, kb tok mindegy miben tarolod, akarmelyik jo lesz. De a tarolasi mod a git eseten nem tamogatja az analizist, mig a masik ket esetben igen. Sot konnyebb aztan barmit rajuk ereszteni (ML, stb).
Szamomra itt inkabb a git a tulzas, mert nem latom, hogy egy valtozas koveto/kezelo rendszer miben segitheti az analizist egy olyan adatszeten amiben nincs valtozas, viszont metaadatokat kellene belole kinyerni.
De oszinten csinald azzal miben a legjobb vagy es a legkonnyebben megcsinalod, mert kar energiat belerakni aabba, amibe nem akar az ember es nem is biztos hogy haszna lesz az energia befektetesebol
Hát az a túlzás, h kell működtetni egy bármi alkatrészt, ha rámtör a rendcsinálhatnék.
he?
Linuxra két ilyen megoldást ismerek, az egyik egy nem túl bizalomgerjesztő, de állítólag normálisan működő lengyel program, a Czkawfka, a másik, sokkal általánosabb megoldás, hogy az új lemezen Btrfs fájlrendszert használsz, és azon bekapcsolod másolás ELŐTT a dedup funkciót. Az utóbbi ugyan nem teljesen szabadul meg a duplikátumoktól, de azok nem foglalnak extra tárhelyet legalább.
MekkelekOS-re meg Nyílászárókra nincs ötletem, hogy azoknál mit érdemes erre használni. Keresőzni tudnék, de azt te is tudsz.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
ez menő lehet, de a work, work1, workN problémát nem oldja meg. Mondjuk a később felszabaduló régi lemezekkel lehet ilyen dolgokat játszani majd.
Arra nem jó talán, de arra meg ott Double Commander, bekapcsolod Ctrl+B-vel a Flat View, itt jó darabon vársz, míg beolvassa az összes mappát, de a végén kilistázza az összes fájlt, mintha egy mappában lenne minden, ott a végén névsorrendbe rendezed, és meglesz a work, work1, work2, stb. csoportosítás, aminek a mentén ki tudod másolni a fájlokat máshová.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Hmm, érdekes ez, az egyetlen konkrétum, amit írtál az a git, azt pont nem értem. Nem látom, mit ad ehhez az egészhez a git funkcióban. Van tizes nagyságrendű lemez, egyszeri átfésülés, és azon aggodalmaskodsz, hogy mi lesz a B terv, ha nincs github?
Olybá tűnik, mintha minden a fejedben valami folyamatosan futó updatelődő izéről szólna, ahol rohadt fontos a skálázhatóság, miközben a megfogalmazott feladatban én sehol nem hallom ezt. Mit nem értek?
Cserében az 1M json metaadatokkal, hát jajj. Mocsadék lassú lesz benne bármit queryzni. Ez alapvetően egy köbvödör stat meg hash számolás, annak az eredményét kell eltenni. Az extrább igényeid is kb annyi, hogy ki kell olvasni a mime specifikus metaadatot valami megfelelő libbel. Ezt megírod valami szimpi nyelven (python, mert van hozzá minden lib, go mert static binary alapból), szépen behányod mondjuk egy sqliteba, aztán ha lefutattad mindenhol, akkor majd összefésülöd az azonos struktúrájú dbket, aztán queryzed kedvedre.
Dokuwiki-t raktam egy raspberry-re, a fontos dolgokat nem szétszórva jegyzetelem.