Fórum Root.cz
Hlavní témata => Software => Téma založeno: jauznevimco 08. 05. 2026, 22:02:05
-
Dobry vecer,
prosim o mensi brainstorming, data mi uz prerustaji pres hlavu :)
1x notas (Windows; 1 TB, vetsina dat je toliko kopie ze SSD NASu, ale zato tyto kopie existuji v ruznych verzich)
1x desktop (Windows; ~5 TB, vychazi opet jako kopie ze SSD NASu, ale nekdy mam u sebe jen notas, kde udelam nejake zmeny, ty si presypu sem a mam to tu vickrat... desktop ma obecne storage jen jako "pracovni disky", samotny uzitecny vystup je vlastne o rozumne velikosti)
1x tichej SSD NAS (Linux; ~5 TB - zere to malo, bezi to furt, je to rychly, tak tam mam takovou "cache" pro velke HDD zalohoviste)
1x hlavni HDD zalohoviste (Linux; ~12 TB - spousta dat je tam proste jen tak pro sichr)
1x HDD cold storage archiviste toho nejdulezitejsiho (Linux; ~6 TB)
Prilezitostne zkousim fusovat do casosberu a mam docela problem si v tech datech udrzet nejakej smysluplnej poradek.
Jsem nekde fuc, SD kartu natroubim do notasu a nazdar, pripadne udelam nejake drobne upravy a odsypu to na SSD storage.
Nekdy za tyden, mesic, objevim SD kartu, chcu si byt jistej, ze ten obsah jako fakt nekde mam, tak to jeste supnu na SSD storage do kouzelne bobtnajici slozky "nove".
Ze SSD storage si to pak presypu do desktopu pro poradne zpracovani, pripadne to ruzne existuje v mnoha verzich.
Jednou za uherak zapnu zalohoviste a presypu jeste tam.
Vysledkem je strasnej gulas, fura duplicit a nakolik storage zdrazuje a misto dochazi, musim uz ty duplicity nejak resit.
Jak z toho nejlip vybruslit?
Docela svizne mi vsechno prechroustal multiplatformni DupeGuru (nazev, datum, a/nebo hash souboru), ale s ohledem na charakter tech dat, co mam, by mi vyhovovalo spis neco, kde si muzu otevrit celej strom filesystemu a vychazet toliko z podobnych slozek, nez to resit v ramci seznamu s duplicitama v radu vyssich desitek tisic...
Nu a dalsi vec je, ze teda bez nejakyho poradnyho syncu a discipliny se uz asi fakt nehnu, veci z karty asi spis presunout, nezli kopirovat...
Udelat si jasno v tom, co ze je "master" (kuriozne to vlastne bude asi spis ona SSD storage, k tomu pristupuju nejvic, pac to bezi furt).
A poresit sync zmen mezi SSD storagem a zalohovistem (pro kazdej file prohledat, jestli tam uz neexistuje... upozornit, pokud chci mit jako master SSD storage a z nej nejakej soubor smaznu, jestli chci tuhle zmenu syncnout i do zalohoviste).
Variantne teda kdyz si vezmu jeste charakter toho, co delam - muze mit smysl si verzi metadat a konfigu k fotkam nacpat do neceho jako SVN, at si muzu prepinat mezi verzema pro lepsi porovnavani, nebo to neni vhodny use case?
Diky za napady.
-
ja by som po upratani urobil asi to, ze na SSD NAS nasadim SVN server, klientov na notas a pocitac.
A potom dajme tomu kazdu noc robit sync z toho SSD NAS na HDD cold storage archiviste - tym zase zabezpecis, ze budes mat zalohu poslednych dat z toho ssd.
Cize cez den sa hrajes na ssd, menis/upravujes a vecer sa ti urobi zaloha na hdd.
To by na nejake udrzanie poriadku a zalohy dolezitych veci mohlo stacit.
kedze asi to budu rozne subory, tak preto radsej svn, ako git.
-
Jak vyřešit už existující "duplicity" (čti: chaos/bordel) takhle zfleku v hlavě úplně nemám ale co se synchronizace týká, striktně se držím modelu "jeden master storage, kde je všechno + soustava strojů obsahující podmnožiny". A bez opravdu dobrého důvodu žádná data nikde jinde. Pak to lze snadno hned, P2P a automaticky synchronizovat přes Syncthing (https://syncthing.net/) a není v tom přesně tenhle binec. Nemuvě o tom, že je to pohodlné a nemusím pořád žonglovat s nějakými transfery odněkud někam.
Samozřejmě mám data i jinde ale to jsou vyloženě specifické domény: cold archiv, kam jde to, o čem vím, že už to potřebovat nejspíš hodně dlouho (roky) nebudu, archiv filmů a médií obecně, archiv fotek.
-
Použil bych Git. Vezmeš nejstarší adresář, dáš git init, git add, git commit. Potom novější soubory přesuneš do tohoto adresáře. Znovu git add, git commit. Přesuneš další a další. Git si už s duplicitami poradí i v případě rozdílných názvů. Starší soubory pak najdeš v historii.
Samozřejmě je nutné soubory rozdělit do projektů, to dá rozum.
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy. Nevidím v tom žádný overkill, prostě to funguje. Skript asi na 6 řádek - bylo to nečekaně rychlé. Prostě stačí výstup sha256sum seřadit a pustit do filtru, který ty duplicity zobrazí, případně rovnou smaže.
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
Nie celkom, už som to robil niekoľkokrát v rôznych verziách so stovkami tisíc súborov. Zvlášť keď sa jedná iba o deduplikáciu, ktorá je oveľa menej náročná ako sa zdá. Vidím tam Windows, používam na takéto veci PowerShell je na to ako stvorený, má prístup aj do .Net aj do Windows API, dajú sa v ňom písať aj testy aj tam funguje TDD. A to isté by malo fungovať aj na Linuxe, v rámci .Net Core, tuším. Prípadne python alebo C# alebo čokoľvek.
Postup v skratke pre PowerShell: získať položky súborov v daných zložkách, to sú objekty, asi typ FileInfo alebo niečo také, zoskupiť podľa veľkosti, iba súbory s rovnakou veľkosťou (celkovo alebo veľkosť prúdu audio/video dát, ak ignorujem popisky) môžu byť duplikáty; pre každú skupinu veľkosti (cyklus alebo ForEach-Objekt) ktorá má viac ako jedného člena pridať objektom FileInfo v aktuálnej skupine cez Add-Member ako vlastnosť prúd na čítanie bloku dát, pridať aj objekt .Net na inkrementálný hash, zistiť si vopred z úložiska minimálnu veľkosť bloku, ktorú má zmysel načítať z disku (lebo keď aj zadám iba 1 bajt, OS aj tak načíta napríklad 4kb), pre danú veľkosť vypočítať koľko blokov zistenej veľkosti potrebujem na danú veľkosť súboru. Počet blokov určí počet iterácii inkrementálneho hashovania, pre každú iteráciu poslať položky aktuálnej skupiny veľkosti súborov do ForEach-Objekt, pre každú položku v bloku toho ForEach-Objekt načítať pre danú iteráciu i-ty blok podľa čísla iterácie, z prúdu, ktorý bol pridaný do položky v predchádzajúcich krokoch, pridať načítané dáta do kontrolného súčtu cez objekt z .Net, ktorý bol tiež pridaný do položky a vrátiť položku ako výsledok. Plus mínus niečo na tento spôsob.
Pokiaľ takto spracované položky chcem zhromaždené v jednom poli, tak ich normálne priradím do premennej, ak nie, tak ich zreťazím v kolóne s ďalším krokom, tým ten ForEach-Objekt nie je blokujúci, ale je ako generátorová korutina, ktorá posiela položky ďalej do ďalšieho kroku, takže keď napríklad v prvom kroku kolóny je piata položka, prvá položka je už v piatom kroku kolóny, ak ani jeden z krokov nie je blokujúci. (+-1, nerozmýšľam, nepočítam to...)
Ďalším krokom tu ale je zoskupenie podľa aktuálnej hodnoty inkrementálneho kontrolného súčtu. To sa asi dá urobiť iba blokujúco, lebo sú nutné všetky položky.
Tým vzniknú skupiny podľa aktuálnej hodnoty inkrementálneho kontrolného súčtu, tie ktoré po prvej iterácii majú iba jedného člena nemajú rovnaký prvý blok, nie sú to teda duplikáty, tým treba iba zatvoriť prúd, prípadne odobrať a aj ten objekt .Net, ktorý inkrementálne hashuje a zabudnúť na ne.
Súbory v skupinách, ktoré majú viac ako jedného člena sú kandidáti na duplikáty a tie je treba v ďalšej iterácii poslať opäť do toho ForEach-Objekt, kde sa načíta druhý blok dát, pridá sa do inkrementálneho kontrolného súčtu a výsledok sa zas zoskupí podľa aktuálnej hodnoty kontrolného súčtu z prvých dvoch blokov.
Takto postupne vypadnú súbory, ktoré nie sú duplikáty, veľa z nich hneď v prvých iteráciách, pre veľa z nich sa teda kontrolný súčet počíta iba z blokov na začiatku, dovtedy, kým nevypadnú z hry a úplný kontrolný súčet sa vypočíta iba z tých súborov, ktoré naozaj duplikátmi sú.
Takže pre deduplikáciu nie je nutné počítať celé kontrolné súčty zo všetkých súborov.
ForEach-Objekt má aj paralelnú verziu, ale je to zložitejšie, lebo je nutné obmedziť podľa typu úložiska počet paralelne bežiacich úloh (NVME zvládne viac, SATA SSD menej, rotačný disk ešte menej, možno iba 1, sieťové som neskúšal), pokiaľ máte všetko z NVME, je to jednoduché, ak nie, tak sa to dá zoskupiť podľa druhu úložiska a jednotlivé skupiny podľa druhu hardvéru riešite oddelene s rôznym obmedzením súbežnosti a pred zoskupením podľa výsledku aktuálnej iterácie kontrolného súčtu to zlúčite do jedného poľa. V PowerShelli je to iba jedna ďalšia úroveň cyklu a to zlúčenie je vzhľadom na vlastnosti kolóny automatické.
Potom sú tam ešte také veci ako odkazy na súbory, pevné alebo symbolické, to je nutné vedieť rozlíšiť, získať cieľový súbor odkazu, nechať v sade iba jeden výskyt, nemá zmysel deduplikovať 10 súborov, keď všetky ukazujú na tie isté dáta, to zistíte aj z Windows API, že sú to fyzicky tie isté dáta prístupné pod viacerými názvami a je lepšie prefiltrovať to vopred.
Robil som aj presúvanie súborov v jednej stromovej štruktúre podľa vzoru ich umiestnenia v inej stromovej štruktúre, a podobné veci, to ale vyžaduje buď úplné kontrolné súčty pre všetko, alebo podľa typu dát, napríklad audio/video súbory sa dá tipnúť si, že keď sú dáta v strede rôzne, celý súbor je rôzny, tak stačí kontrolný súčet z kúsku dát.
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy. Nevidím v tom žádný overkill, prostě to funguje. Skript asi na 6 řádek - bylo to nečekaně rychlé. Prostě stačí výstup sha256sum seřadit a pustit do filtru, který ty duplicity zobrazí, případně rovnou smaže.
no u nekolika gigoveho filmu mi ten hash trval i 10s, tak to se mi nechtelo zase tak cekat, takze jsem nejprve porovnaval jen nazvy adresaru a souboru.
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy. Nevidím v tom žádný overkill, prostě to funguje. Skript asi na 6 řádek - bylo to nečekaně rychlé. Prostě stačí výstup sha256sum seřadit a pustit do filtru, který ty duplicity zobrazí, případně rovnou smaže.
no u nekolika gigoveho filmu mi ten hash trval i 10s, tak to se mi nechtelo zase tak cekat, takze jsem nejprve porovnaval jen nazvy adresaru a souboru.
Potřeboval jsem deduplikovat shodné soubory s potenciálně různými názvy v různých adresářích. Přes sha256 jsem měl napsán skript asi za 5 minut. Než jsem si uvařil kafe, bylo deduplikováno. Nedělám to každý den, optimalizace tedy nedává smysl.
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
.
Postup v skratke pre PowerShell: ...
Ve Windows je to tak komplikované? No jo, nemají roury...
-
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...), a rozdělil bych to tedy na "spočítej hash pro všechno a ulož do sqlite" a pak dál pracoval už jen s tou sqlite (protože dělat random seek v txt, co má pár MB, taky není nejrychlejší, když to děláš milionkrát).
-
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...), a rozdělil bych to tedy na "spočítej hash pro všechno a ulož do sqlite" a pak dál pracoval už jen s tou sqlite (protože dělat random seek v txt, co má pár MB, taky není nejrychlejší, když to děláš milionkrát).
Jaký random seek? Proženu to sortem a projdu sekvenčně
-
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...)
Práveže ak chcete iba nájsť presné duplicity, tak všetky tie TB dát cez CPU prehnať nemusíte, stačia iba tie, ktoré sú bezpodmienečne nutné.
Dúfal som, že to bude z mojej odpovede jasné. Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.
-
Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.
Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?
-
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
.
Postup v skratke pre PowerShell: ...
Ve Windows je to tak komplikované? No jo, nemají roury...
Njn, ešte stále sa stáva, že tu niekto "trollí", ale to že sa nájde niekto, kto má problém s chápaním písaného textu, porovnáva neporovnateľné a vyjadruje sa tak ako vy, ma už v tejto dobe naozaj trochu prekvapuje.
PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.
To máte ako s vláknom, mne sa tiež slovo vlákno nepáči, ale akceptujem, že ho niekto kedysi dávno z nejakých dôvodov zaviedol.
Tu máte článok, kde je to slovo použité, myslím, že médium, kde je ten článok publikovaný je v odbornej komunite celkom rešpektované: https://www.root.cz/clanky/terminaly-tajemstvi-zbavene-procesy-a-signaly/
Je k tomu aj celkom výživná diskusia, kde sú uvedené dôvody prečo toto slovo a prečo ho niektorí nechápu.
Pokiaľ ale máte pocit, že som niečo mohol napísať inak a že je chyba na mojej strane, čo sa mohlo stať, písal som to v noci, rád sa dozviem čo, nech sú moje príspevky v budúcnosti jednoduchšie na pochopenie.
Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.
Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?
V akom prípade? keď je kontrolný súčet za prvých n blokov rovnaký alebo rôzny?
- ak je kontrolný súčet za prvých n blokov rôzny, tak vás blok n+1 nezaujíma, lebo tie súbory na základe prvých n blokov nemôžu na byť duplikátmi a v iterácii n ste ich z vyradili, takže v iterácii n+1 vôbec nie sú, pretože kontrolný súčet z nich nepočítate, lebo nemusíte, keďže viete z predchádzajúcej iterácie, že tie súbory nie sú duplikátmi.
- ak je ale kontrolný súčet za prvých n blokov rovnaký, tak ten rozdiel v jednom bajte zistíte v iterácii n+1, do iterácie n sú súbory kandidátmi na duplikáty, ale v iterácii n+1 nimi byť prestanú a tiež ich vyradíte z ďalšieho spracovania
Inak, mohol som asi použiť i na označenie čísla iterácie, ale to už je teraz jedno.
-
Ve Windows je to tak komplikované? No jo, nemají roury...
PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.
Pokud vím, tak Windows mají stále parodii na roury přes dočasné soubory. Není to efektivní a proto je uživatelé moc nepoužívají. Zejména při zpracování velkých souborů je to problém.
Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?
- ak je ale kontrolný súčet za prvých n blokov rovnaký, tak ten rozdiel v jednom bajte zistíte v iterácii n+1, do iterácie n sú súbory kandidátmi na duplikáty, ale v iterácii n+1 nimi byť prestanú a tiež ich vyradíte z ďalšieho spracovania
Inak, mohol som asi použiť i na označenie čísla iterácie, ale to už je teraz jedno.
Takže ty soubory stejně musím projít celé, ale už chápu, že jen některé.
-
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...)
Práveže ak chcete iba nájsť presné duplicity, tak všetky tie TB dát cez CPU prehnať nemusíte, stačia iba tie, ktoré sú bezpodmienečne nutné.
Aha, pardon, asi jsem ještě neměl dost kofeinu v krvi. :-)
-
Ve Windows je to tak komplikované? No jo, nemají roury...
PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.
Pokud vím, tak Windows mají stále parodii na roury přes dočasné soubory. Není to efektivní a proto je uživatelé moc nepoužívají. Zejména při zpracování velkých souborů je to problém.
Je možné, že si mýlite operačný systém a programovací jazyk? To by sa v kombinácii s tým ako autoritatívne sa vyjadrujete k príspevkom ostatných asi nemalo stávať.
Jasne píšem, že je to pre PowerShell a ten predsa beží aj na Linuxe aj na MasOS. Tak prečo do toho montujete Windows, mimochodom vo verzii 95, možno 98? Odvtedy už tie veci, ktoré spomínate fungujú inak a to už je minimálne štvrť storočia. Okrem toho v prvej odpovedi spomínam aj iné programovacie jazyky. Mechanizmus vyraďovania súborov, ktoré nie sú duplikátmi ostane rovnaký.
Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?
- ak je ale kontrolný súčet za prvých n blokov rovnaký, tak ten rozdiel v jednom bajte zistíte v iterácii n+1, do iterácie n sú súbory kandidátmi na duplikáty, ale v iterácii n+1 nimi byť prestanú a tiež ich vyradíte z ďalšieho spracovania
Inak, mohol som asi použiť i na označenie čísla iterácie, ale to už je teraz jedno.
Takže ty soubory stejně musím projít celé, ale už chápu, že jen některé.
Áno, ale iba tie, ktoré sú naozaj duplikátmi, tomu sa nedá zabrániť, ak chceta mať istotu. Veľa z tých, ktoré duplikátmi nie sú vypadne v prvých iteráciách.
-
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...)
Práveže ak chcete iba nájsť presné duplicity, tak všetky tie TB dát cez CPU prehnať nemusíte, stačia iba tie, ktoré sú bezpodmienečne nutné.
Aha, pardon, asi jsem ještě neměl dost kofeinu v krvi. :-)
To nevadí, nemám problém niečo zopakovať. Je fakt, že tá moja prvá odpoveď bola dosť dlhá.
-
Koukam ze neni nad to vymejslet kolo ...
btrfs = vsechno na jednom storage, deduplikace na urovni FS. Nijak jinak to stejne udelat nejde, nebude to fungovat.
Samozrejme pripadne od toho mit nejaky backup, ktery se opet muze delat rozdilove prostrednicvim btrfs snapu.
Nevim o jak moc velkej domaci bordelak se jedna, ale ve firemnich bordelacich je redukce dat mezi 50-80%. Nema totiz zadnej smysl lidem vysvetlovat, ze si vazne nemusej kazdou chujovinu ukladat "k sobe". At to tam tudiz klidne maj, a klidne kazdej jeden 100x.
Ovsem pokud ten domaci bordelaj je alespon castecne svepravnej, necekej od toho vic nez 30%. Neco malo navic se da prihodit zapnutim komprese, coz ma tu vyhodu, ze medialni soubory se nekomprimujou, protoze to pozna ze to nema smysl.
-
Koukam ze neni nad to vymejslet kolo ...
btrfs = vsechno na jednom storage, deduplikace na urovni FS. Nijak jinak to stejne udelat nejde, nebude to fungovat.
Samozrejme pripadne od toho mit nejaky backup, ktery se opet muze delat rozdilove prostrednicvim btrfs snapu.
Nevim o jak moc velkej domaci bordelak se jedna, ale ve firemnich bordelacich je redukce dat mezi 50-80%. Nema totiz zadnej smysl lidem vysvetlovat, ze si vazne nemusej kazdou chujovinu ukladat "k sobe". At to tam tudiz klidne maj, a klidne kazdej jeden 100x.
Ovsem pokud ten domaci bordelaj je alespon castecne svepravnej, necekej od toho vic nez 30%. Neco malo navic se da prihodit zapnutim komprese, coz ma tu vyhodu, ze medialni soubory se nekomprimujou, protoze to pozna ze to nema smysl.
Tak já třeba mám redundaci tak u něčeho i 400-600% kvulivá každoročnímu stažení kompletních projektových dat, kdy ty projekty běžej 4-6 let, takže některý soubory klidně několikrát bezezměny, jiný úplně se stejným názvem pokaždý jiný... to se fakt ta deduplikace dělá dooost blbě... snažil jsem se několikrát, nelíp se mi jevilo sehrát to všechno k sobě ale poté co jsem si přemazal staršíma souborama novější jsem od toho upustil a jenom to celý pokaždý zipnu a dokoupil jsem větší disk.
-
Ve Windows je to tak komplikované? No jo, nemají roury...
PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.
Pokud vím, tak Windows mají stále parodii na roury přes dočasné soubory. Není to efektivní a proto je uživatelé moc nepoužívají. Zejména při zpracování velkých souborů je to problém.
Je možné, že si mýlite operačný systém a programovací jazyk? To by sa v kombinácii s tým ako autoritatívne sa vyjadrujete k príspevkom ostatných asi nemalo stávať.
Jasne píšem, že je to pre PowerShell a ten predsa beží aj na Linuxe aj na MasOS. Tak prečo do toho montujete Windows, mimochodom vo verzii 95, možno 98? Odvtedy už tie veci, ktoré spomínate fungujú inak a to už je minimálne štvrť storočia. Okrem toho v prvej odpovedi spomínam aj iné programovacie jazyky. Mechanizmus vyraďovania súborov, ktoré nie sú duplikátmi ostane rovnaký.
V Linuxu je podpora pipe službou operačního systému, není tedy součástí aplikace. Vůbec nevyužívá souborový systém, data jdou od producenta ke konzumentovi přes velmi malou část operační paměti. Ve Windows je podpora emulována přes soubory a tím má mizerný výkon. Netuším, zda to v pozdějších verzích napravili, ale nemám to jak zjistit. V desítkách to ještě nebylo a obávám se, že to tam stále není.
-
Ve Windows je to tak komplikované? No jo, nemají roury...
PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.
Pokud vím, tak Windows mají stále parodii na roury přes dočasné soubory. Není to efektivní a proto je uživatelé moc nepoužívají. Zejména při zpracování velkých souborů je to problém.
Je možné, že si mýlite operačný systém a programovací jazyk? To by sa v kombinácii s tým ako autoritatívne sa vyjadrujete k príspevkom ostatných asi nemalo stávať.
Jasne píšem, že je to pre PowerShell a ten predsa beží aj na Linuxe aj na MasOS. Tak prečo do toho montujete Windows, mimochodom vo verzii 95, možno 98? Odvtedy už tie veci, ktoré spomínate fungujú inak a to už je minimálne štvrť storočia. Okrem toho v prvej odpovedi spomínam aj iné programovacie jazyky. Mechanizmus vyraďovania súborov, ktoré nie sú duplikátmi ostane rovnaký.
V Linuxu je podpora pipe službou operačního systému, není tedy součástí aplikace. Vůbec nevyužívá souborový systém, data jdou od producenta ke konzumentovi přes velmi malou část operační paměti. Ve Windows je podpora emulována přes soubory a tím má mizerný výkon. Netuším, zda to v pozdějších verzích napravili, ale nemám to jak zjistit. V desítkách to ještě nebylo a obávám se, že to tam stále není.
Vy si naozaj mýlite operačný systém a programovací jazyk. To že je na jednej platforme niečo implementované nejako neznamená, že to tak nutne musí byť implementované aj na iných platformách.
Už som vám naznačoval, že to, čo ste popisovali, je už viac ako 25 rokov vyriešené a teda žiadne súbory tam nie sú. A okrem toho, v PowerShelli idú dáta cez kolónu k spotrebiteľovi cez ešte menšiu časť pamäte ako v Linuxe. Dokumentácia aj zdrojový kód sú tuším otvorené a verejne dostupné.
-
Už som vám naznačoval, že to, čo ste popisovali, je už viac ako 25 rokov vyriešené a teda žiadne súbory tam nie sú. A okrem toho, v PowerShelli idú dáta cez kolónu k spotrebiteľovi cez ešte menšiu časť pamäte ako v Linuxe. Dokumentácia aj zdrojový kód sú tuším otvorené a verejne dostupné.
Dá se to poznat tak, že tou rourou pošlu třeba 200 GB dat, když je jen 100 GB volného místa v úložišti. Pokud mám pravdu, tak to zkolabuje. Pokud nemám pravdu, tak to proběhne během několika málo sekund.
Ve Windows 10 mi to zkolabovalo.
-
Už som vám naznačoval, že to, čo ste popisovali, je už viac ako 25 rokov vyriešené a teda žiadne súbory tam nie sú. A okrem toho, v PowerShelli idú dáta cez kolónu k spotrebiteľovi cez ešte menšiu časť pamäte ako v Linuxe. Dokumentácia aj zdrojový kód sú tuším otvorené a verejne dostupné.
Dá se to poznat tak, že tou rourou pošlu třeba 200 GB dat, když je jen 100 GB volného místa v úložišti. Pokud mám pravdu, tak to zkolabuje. Pokud nemám pravdu, tak to proběhne během několika málo sekund.
Ve Windows 10 mi to zkolabovalo.
Nehnevajte sa, ale vy naozaj pôsobíte v IT? Nemyslím si, že má pre mňa zmysel pokračovať v debate s niekým, kto očividne nepozná rozdiel medzi programovacím jazykom a operačným systémom, kto sa nenamáha prečítať si navhrnuté riešenie predtým ako sa k nemu vyjadrí a kto sa neobťažuje zistiť si ako veci v skutočnosti fungujú na iných platformách, napriek tomu, že dostane informáciu, že je všetko prístupné a že veci už dávno fungujú inak ako si celé roky myslí.
Neviem, čo vám skrachovalo, v podstate ma to ani nezaujíma, neobťažovali ste sa sem vlepiť príkazy, ktoré ste použili, dohadovať sa o tom, čo to bolo a riešiť to je pre mňa strata času, ale z toho popisu, čo ste sem dali si myslím, že je to úplne mimo kontext toho, čo som písal ja, aj mimo mnou navrhnutého riešenia, pretože v tom nikto žiadne veľké dáta cez kolónu neposiela. To nakoniec v PowerShelli v rámci jeho štandardnej knižnice celkovo nerobí nikto, posielaný je odkaz na objekt .Net obsahujúci metadáta týkajúce sa položky súborového systému, ako napríklad cesta, dátumy, veľkosť, vlastnosti, atď., prípadne ďalšie pridané vlastnosti. Dáta zo súboru sú načítavané prúdom .Net po častiach, inkrementálny hash je tiež počítaný objektom z .Net. To všetko je uvedené už v mojom prvom príspevku.
Správate sa ako troll, ktorý, keď vidí niekde napísané Windows, jednoducho sa potrebuje vyjadriť, že Windows je šmejd, napriek tomu, že daná téma sa Windows vôbec nijako netýka. Okrem toho, že predrečník má vo Windows dáta. Ale má ich aj na Linuxe a PowerShell funguje aj tam. Podobnú skupina tvoria ľudia, ktorí sa správajú rovnako, keď vidia niekde napísané C++. Nebol by som prekvapený, keby ste boli členom oboch skupín.
Ja osobne som do tejto témy zapojil výhradne kvôli tomu, že tu predtým panoval názor, že je nutné kvôli deduplikácii počítať hash z celého objemu dát všetkých súborov, čo teda ani náhodou nie je pravda a aspoň toto si už možno uvedomujete aj vy, takže som rád, že som to mohol objasniť a možno trochu zjednodušiť život aj vám a to napriek tomu, že ste písali, že je to optimalizácia, ktorá nie je potrebná.
Ostatné veci už s dovolením nechávam na vaše samoštúdium.
-
Neviem, čo vám skrachovalo, v podstate ma to ani nezaujíma, neobťažovali ste sa sem vlepiť príkazy, ktoré ste použili, dohadovať sa o tom, čo to bolo a riešiť to je pre mňa strata času, ale z toho popisu, čo ste sem dali si myslím, že je to úplne mimo kontext toho, čo som písal ja, aj mimo mnou navrhnutého riešenia, pretože v tom nikto žiadne veľké dáta cez kolónu neposiela. To nakoniec v PowerShelli v rámci jeho štandardnej knižnice celkovo nerobí nikto, posielaný je odkaz na objekt .Net obsahujúci metadáta týkajúce sa položky súborového systému, ako napríklad cesta, dátumy, veľkosť, vlastnosti, atď., prípadne ďalšie pridané vlastnosti. Dáta zo súboru sú načítavané prúdom .Net po častiach, inkrementálny hash je tiež počítaný objektom z .Net. To všetko je uvedené už v mojom prvom príspevku.
Přes kolonu běžně posílám desítky GB dat. Jednoduchý příkaz:
tar czvf - adresář | gzip > archiv.tgzFunguje to skvěle, rychle a využiji tím 2 jádra procesoru současně.
Pro deduplikaci souborů:
sha256sum . | sort | filtr_mazající_duplicity
-
Neviem, čo vám skrachovalo, v podstate ma to ani nezaujíma, neobťažovali ste sa sem vlepiť príkazy, ktoré ste použili, dohadovať sa o tom, čo to bolo a riešiť to je pre mňa strata času, ale z toho popisu, čo ste sem dali si myslím, že je to úplne mimo kontext toho, čo som písal ja, aj mimo mnou navrhnutého riešenia, pretože v tom nikto žiadne veľké dáta cez kolónu neposiela. To nakoniec v PowerShelli v rámci jeho štandardnej knižnice celkovo nerobí nikto, posielaný je odkaz na objekt .Net obsahujúci metadáta týkajúce sa položky súborového systému, ako napríklad cesta, dátumy, veľkosť, vlastnosti, atď., prípadne ďalšie pridané vlastnosti. Dáta zo súboru sú načítavané prúdom .Net po častiach, inkrementálny hash je tiež počítaný objektom z .Net. To všetko je uvedené už v mojom prvom príspevku.
Přes kolonu běžně posílám desítky GB dat. Jednoduchý příkaz:
tar czvf - adresář | gzip > archiv.tgzFunguje to skvěle, rychle a využiji tím 2 jádra procesoru současně.
Pro deduplikaci souborů:
sha256sum . | sort | filtr_mazající_duplicity
A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?
Prípadne, má to niečo spoločné s mojou poslednou odpoveďou? Že neviem, čo konkrétne a kde konkrétne ste písali, keď vám to skolabovalo?
Táto konkrétna vec totiž na Windows funguje principiálne rovnako ano na Linuxe. S prihliadnutím na rozdiely v API a v modeli procesov a vlákien. Asi tak od čias NT 3.1. To bol rok asi tak 1993. Už som vám to niekoľkokrát opakoval. Ale je to márne, je to márne, je to očividne márne.
Záver pre mňa: niekde ste počuli niečo, čo platilo pre Windows 95 a ste schopný opakovať to do nekonečna bez toho aby ste sa obťažovali vyhľadať si ako to v skutočnosti je. Plus si ešte mýlite operačný systém a programovací jazyk. Ale to už som písal.
-
Neviem, čo vám skrachovalo, v podstate ma to ani nezaujíma, neobťažovali ste sa sem vlepiť príkazy, ktoré ste použili, dohadovať sa o tom, čo to bolo a riešiť to je pre mňa strata času, ale z toho popisu, čo ste sem dali si myslím, že je to úplne mimo kontext toho, čo som písal ja, aj mimo mnou navrhnutého riešenia, pretože v tom nikto žiadne veľké dáta cez kolónu neposiela. To nakoniec v PowerShelli v rámci jeho štandardnej knižnice celkovo nerobí nikto, posielaný je odkaz na objekt .Net obsahujúci metadáta týkajúce sa položky súborového systému, ako napríklad cesta, dátumy, veľkosť, vlastnosti, atď., prípadne ďalšie pridané vlastnosti. Dáta zo súboru sú načítavané prúdom .Net po častiach, inkrementálny hash je tiež počítaný objektom z .Net. To všetko je uvedené už v mojom prvom príspevku.
Přes kolonu běžně posílám desítky GB dat. Jednoduchý příkaz:
tar czvf - adresář | gzip > archiv.tgzFunguje to skvěle, rychle a využiji tím 2 jádra procesoru současně.
Pro deduplikaci souborů:
sha256sum . | sort | filtr_mazající_duplicity
A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?
... pretože v tom nikto žiadne veľké dáta cez kolónu neposiela.
A to je lež. Už jsem přes kolonu posílal i víc než 1 TB dat, například při kopírování velkého množství souborů mezi disky. Je to rychlejší než příkazem cp a skvěle to funguje i přes ssh.
Táto konkrétna vec totiž na Windows funguje principiálne rovnako ano na Linuxe. S prihliadnutím na rozdiely v API a v modeli procesov a vlákien. Asi tak od čias NT 3.1. To bol rok asi tak 1993. Už som vám to niekoľkokrát opakoval. Ale je to márne, je to márne, je to očividne márne.
Kdyby to ve Windows fungovalo stejně jako v Linuxu, tak by to programátoři používali mnohem častěji, protože je to nejrychlejší možná komunikace mezi běžícími procesy. Množství dat není nijak omezeno velikostí volné operační paměti ani volného místa na úložišti. Píšeš, že v PowerShellu se předává jen odkaz na objekt. Jaký objekt, když procesy mají oddělené adresové prostory? Jedině přes operační systém. A přesně tak to dělají kolony.
-
A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?
... pretože v tom nikto žiadne veľké dáta cez kolónu neposiela.
A to je lež.
Lež??? Akože viem, že je to inak a úmyselne vás klamem? Ako si niečo také vôbec môžete dovoliť? Kto si myslíte, že ste???
Už jsem přes kolonu posílal i víc než 1 TB dat, například při kopírování velkého množství souborů mezi disky. Je to rychlejší než příkazem cp a skvěle to funguje i přes ssh.
To pre mňa vôbec nie je relevantné, ja som písal o mojom riešení, teda a o tom ako to má PowerShell.
Kdyby to ve Windows fungovalo stejně jako v Linuxu, tak by to programátoři používali mnohem častěji, protože je to nejrychlejší možná komunikace mezi běžícími procesy. Množství dat není nijak omezeno velikostí volné operační paměti ani volného místa na úložišti. Píšeš, že v PowerShellu se předává jen odkaz na objekt. Jaký objekt, když procesy mají oddělené adresové prostory? Jedině přes operační systém. A přesně tak to dělají kolony.
S takouto mierou nekompetentnosti som sa tu ešte (asi) nestretol. Ale dobre, tak ešte jeden pokus. A pomaly, pre extrémne nechápavých:
Jeden z vašich najväčších problémov, teda okrem toho, že ste troll, je v tom, že si mýlite dojmy s pojmami. Opakovane som vás upozorňoval, že si mýlite operačný systém s programovacím jazykom. Ale nezabralo to.
Moje riešenie používa PowerShell. PowerShell je viac vecí v jednom. Jedna z nich je hostiteľ príkazového riadku. V kontexte môjho riešenia je ale PowerShell použitý ako programovací jazyk.
PowerShell ako taký je normálny používateľský proces a s operačným systémom nemá vôbec nič spoločné. Existujú v ňom kolóny, je to jednoducho abstrakcia postupného spracovania vo viacerých fázach, ale sú implementované na inej úrovni abstrakcie ako kolóny operačného systému.
Nepoužívajú na prenos medzi jednotlivými fázami zápis na štandardný vstup a čítanie zo štandardného vstupu, ale odkaz na objekt. A nie je to žiadny problém, lebo je to všetko v jednom procese. V kontexte PowerShellu totiž používate interné nástroje z jeho štandardnej knižnice, a až keď potrebujete pracovať s externým programom, prenos prechádza cez dáta. Ale aj ten je realizovaný najlepšie ako sa v rámci jeho podkladovej platformy, ktorou je .Net/CLR dá, keby to malo byť pre moje riešenie náhodou dôležité. Zjednodušene povedané.
Všetky vaše poznámky o kolónach vo Windows sú v tomto kontexte teda absolútne mimo. Mnou navrhnuté riešenie nemá s Windows nič spločné. Vy ste doteraz za celé tie roky naozaj nezaregistrovali, že PowerShell funguje aj na Linuxe aj na MacOS?
Čo sa Windows týka, tak tá legenda o dočasných súboroch, ktorú si v komunite asi často opakujete, keď pretrvala štvrtinu storočia po tom ako prestala byť platná, sa týka kolóny v command.com, ten bol naposledy v spotrebiteľskej verzii systému vo Windows 95, možno Windows 98. V podnikovej verzii systému ale už v tej dobe existoval cmd.exe, ktorý bol v podstate prevzaný z OS/2. To bolo asi vo Windows NT 3.1. A cmd.exe používa úplne rovnaký mechanizmus ako Unix.
Minimalistický zdroj, ktorý to potvrdzuje, nájdete tu: https://en.wikipedia.org/wiki/Cmd.exe
Stačí vám to tak? Obávam sa, že nie, tak som špeciálne kvôli vám nechal vygenerovať trochu podrobnejší popis. Samozrejme som to nepísal ja osobne, je to Claude. Požiadal som, aby sa to dalo dobre čítať. Na základe skúsenosti s vami sa zdá, že máte naozaj problémy s chápaním písaného textu.
Na konci máte špeciálny zoznam pre ľudí ako ste vy, teda takých, ktorí keď niekde vidia spomenuté Windows, musia si uľaviť, tak ako pod mojím prvým príspevkom. Celé je to inak celkom zaujímavé čítanie, ktoré by normálnym ľuďom mohlo trochu otvoriť oči o tom aká je história operačných systémov, čo odkiaľ pochádza, čo je odkiaľ prevzaté, atď. Asi si nerobím úplne ilúzie, že by ste to chceli čítať, ale aj tak. Možno si to prečíta niekto iný.
Je to v prílohe ako súbor v markdown.
-
A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?
... pretože v tom nikto žiadne veľké dáta cez kolónu neposiela.
A to je lež.
Lež??? Akože viem, že je to inak a úmyselne vás klamem? Ako si niečo také vôbec môžete dovoliť? Kto si myslíte, že ste???
Pokud jsi jen nevzdělaný, tak se omlouvám. Skutečností je, že v linuxovém světě se kolony běžně používají pro přenos velkých objemů dat, která by se do dočasných objektů ani nemohla vejít.
Ve Windows se takové objemy nepoužívají a proto si vystačí s objekty uloženými v .NET . Pro spuštění kolony v rámci PowerShellu se tedy využívá tato mezivrstva. Pokud však jedním z členů komunikace je vnější proces, tak tuto službu zprostředkovává přímo jádro operačního systému, kterou si PowerShell obalí tak, že uživatel má pocit, že přenos dat dělá přímo PowerShell bez účasti jádra operačního systému.
V Linuxu však .NET ani PowerShell standardně nejsou, takže meziprocesová komunikace se nejjednoduššeji dělá právě pomocí služeb jádra operačního systému.
-
protoze to fakt nevim, co je to kolona? jako pipeline?
-
protoze to fakt nevim, co je to kolona? jako pipeline?
Podle kontextu roura (pipe).
-
protoze to fakt nevim, co je to kolona? jako pipeline?
Slova pipe, roura a trubka se používají jako synonyma. Pipeline a kolona znamenají kaskádu pipe či trubek.