Inlägg

Japp - det kan vara så enkelt då den nautulius du startade med sudo i terminal fick root-rättigheter och därmed kan tex. ändra rättigheter.

Ett kytum är att man kör som root i så kort tid som möjligt - dvs. när jobbet är gjort så klickar man bort det igen så att det stängs.

terminalfönster stänger man snabbast med 'ctrl-d' istället för att hela tiden skriva 'exit <enter>' - vilket är bra om man är i flera nivåer djupt ned med 'ssh' i olika datorer och kanske VM-maskiner inuti dessa. - då trycker man 'ctrl-d' upprepande.

---

Du verkar osäker på det där med 6TB och 5.6 TiB, men det är samma mängd lagring men storleken presenterad på 2 olika sätt för samma mängd data där 6 TB är storleken i SI-definition (där 1 TB = 1000000000000 byte, 10¹²) och 5.6 TiB är storleken i binär prefix (och där 1 TiB = 1 099 511 627 776 byte, 2⁴⁰) - lagring har alltid sedan 1960-talet presenterat sin storlek i decimal prefix dvs. 1000 byte är 1 kByte, 1000000 byte är 1 Mbyte. Och det berodde på att tidig lagring så räknade man det som antalet dataposter lagringen kunde hantera och det behövde nödvändigtvis inte vara 8 bit stora poster (dvs 1 byte) utan kunde vara 14 eller 17 bit stora.

se vidare i tex. https://sv.wikipedia.org/wiki/Mebibyte

Det är tyvärr olika beroende på generation av programvaror under linux vilket som visas och det är inte alltid att man skriver i TiB när man menar TiB utan skriver som TB etc. - trots att man har hållit på lätt över 20 år med att få programmen att presentera storlekarna med rätt prefix så är det fortfarande mycket kvar...

Windows gör konsekvent fel att skriva datastorlekar i binär prefix i formen som decimal prefix där 1024 = KB, 1048576 = MB när det istället borde ha hetat KiB och MiB.

BTRFS kan du dock inte använda i windows... (finns väl några försök till drivrutin-support för windows men jag skulle inte använda dem - titta på hur gamla de är om det är flera år sedan sista uppdateringen så skulle jag låta det vara)

En annan regel är att koppla ur alla diskar med viktig data fysiskt som att rycka ur sladden innan du ens tänker på ordet 'formatera' - i alla fall innan du är riktigt varm i kläderna och förstår hur allt fungerar inklusive att identifiera rätt diskar i farliga lägen som att 'formatera' (och det kan göras misstag ändå...)

Ditt problem just nu tror jag att disken du formaterade är satt med root-rättigheter med root som ägare och root som grupp.

du som 'vanlig' användare kan inte komma åt denna i det här läget utan att göra en 'sudo' på kommandona och den vägen skaffar roträttigheter för operationen. det är lite som att göra sig till admin windows fast mycket mer mäktig.

En fulväg förbi det om du tänker köra grsync på disken fast det är satt som root är att i terminal starta grsync med 'sudo grsync' och programmet startar rent grafisk men nu arbetar som root och med root-rättigheter och då kan du förmodligen synka filerna fast inkopplade USB-disk filsystem är ägd av root

du verkar ha en del att lära dig med Linux så gör dina experiment med lagring och diskar där det inte gör så mycket om du förlorar dina data - det är misstagen man lär sig på och det kan ta ett tag innan man greppar filosofin bakom då det är en del saker som skiljer sig från tex. windows.

Med kommandot 'chown' kan du ändra ägandeskaper på mappar och volymer

och formatet kan vara liknande "sudo chown -v jorgen:jorgen /media/användare1/inkopplade_usb_diskens_mapp" i en terminalfönster. Med '-r eller -R' som växel så går det rekursivt ned i mappträdet och ändrar ägandeskap på alla filer och mappar under det - 'sudo' för att få roträttigheter för att hantera diskar och mappar som du normalt som användare inte rår över.

om du inte vet vad du kallas i systemet så kan du prova med 'ls -la' i din hemma-mapp i ett terminalfönster - då ser du namnen på user och group för dina filer i hemmamappen och disken inkopplad på /media/jorgen/USB-disken (jag såg ditt användarnam i dina tidigare inskickade bilder)

Räkna med att du få slå ett password i dessa fall (kör du 'sudo' för olika funktioner i samma terminal så behövs passwordet bara första gången)

den andra kommandot du behöver titta på är 'chmod' som man kan ställa in skriv, läs och exekveringsrättigheter för 'user', 'group' och 'other'

till skillnad från windows som gör ett uppslag i en bunt olika databaser i avseende rättigheter för var filförfrågan (och ingen koll alls görs om man sätter sig över denna nivå som 'system' och man kan komma åt alla filer oreserverat - det är det alla virus under åren hela tiden försöker hitta väg igenom och lyckas allt för ofta) så är denna rättighetsmatris satt i inoden för filen och varje del i linux och linuxkärnan lyder det blint - tom. på nivå när den skall allokera RAM-minne för programmet som skall köras och stämmer det inte med rättigheterna och vad miljön tillåter så går det inte att köra - och till skillnad från windows rättighetsuppslag så är denna koll blixtsnabb och görs var gång filen accessas.

Det du måste acceptera med tiden är att väldigt många av kommandona som används för att administrera linux är CLI-kommandon som körs i terminal - det fins inte GUI-program för allt och många av de som fins är wrapper för de egentliga CLI-kommandona som görs - grsync är ett exempel på wrapper-program av den riktiga 'rsync' att den tillverkar en CLI-kommandorad som sedan exekveras när du trycker på kör.

Även poweruser i windows kör mycket av sin administrativa uppdrag via powershell eller i värsta fallet CMD.exe av anledningen att det går att skripta medans sådan är besvärligt att göra via en GUI för upprepande processer.

HP42s tog med sig många av funktionerna som först implementerades i HP28C/HP28S - bl.a att man gjorde komplexa tal som en egen datatyp och samtidigt gjorde att alla matematiska funktioner också kunde hantera komplex datatyp - i princip så implementerade man alla de komplexa funktioner som språket Lisp hade i sig och med samma gränser.

HP28C största problem när den en gång begav sig var bristen på RAM-minne och var bara 2 kByte och därför kom det ganska snart ut HP28S med 32 Kbyte RAM - för på den tiden var det dyrt med RAM och speciellt statisk RAM som på dessa miniräknare.

Och samma sak ser man på orginalversionerna av hp10, hp1, hp12 (bussines-räknaren som säljs än idag), hp15C (som tydligen har en collectors edition rullande just nu) och den mycket sällsynta programmerare-räknaren hp16 med rätt begränsade antal programsteg och i hp15c fall försvann 5 lagringsregister när man slog på komplexa delen och att lagringsregister kunde omvandlas till programsteg (7 programsteg per register) när man hade förbrukat upp ordinarie utrymmet programminne.

HP42S hade 8 kByte RAM, dock har jag aldrig hittills kört slut på den

HP:s räknare behövde man sällan byta batterier och det var batteriets egna självurladdning som satte gränsen, billiga nonamebatterier höll mycket kortare tid än märkesbatterier, jag vet då jag har provat några uppsättningar under åren - det fins ett dokumenterad fall där batterierna som följde med räknare (hp12C) höll i 30 år.

ECC-RAM error är nedanför nivån av vad en linuxkärna kan styra och ställa över utan det är kompabilitetsproblem/missmatch mellan minneskontrollern och använda RAM-minne där ev. minnesträning utförd av BIOS inte hittat någon sweet-spot i timingen för hög felfrihet...

Byte till annan märke ECC-RAM visar också på beroendet och förmodligen hade annan moderkort också gett skillnad.

Vad glad att det var ECC-minne i burken som rättade felen och inte vanlig speldatormoderkort då den typen av fel hade kunna pågått länge och orsaka bitflippar i lagrad data och det kan ta väldigt lång tid innan något sådant upptäcks och en zipfil plötligt inte längre kan packas upp pga. crc-fel eller en VM-maskin som upplevs krachbenägen i vissa situationer - eller som här backup körs och förmodligen mer minne tas i anspråk under processen men den dåliga delen av RAM är annars normalt utanför working-set.

och köp på kreditkort (inte betalkort) så att du kan reklamera när det slutar att fungerar, även många år efter köpet.

I dom fallen är det kreditbolagen som bedömer om det är möjligt att reklamera - inte spelbolagen eller vad som står i deras villkor, och i många fallen har kreditkortsbolagen en nöjd-kund-garanti/försäkring och betalar tillbaka pengarna vid minsta missnöje och det kan inte spelbolagen göra något åt när motsvarande pengasumma dras av i intäktsströmmen innan de når spelbolagen.

Att det tar mer plats på din externa lagring än källan är förmodligen att NTFS på din stora disk troligen har större minsta datablock, vilket gör att även varje liten fil drar mer plats.

Det andra som du troligen åker på om det är systemdisken du kopierar ifrån är att windows är en stor användare av hårda länkar och om man inte har rätt flagga så kopieras detta som unika filer och därmed tar mer plats, full utrymme för var kopia.

för att undvika det och de hårdlänkade filerna i källan också bli hårdlänkade i målsidan så behöver du markera ett par bockar till.

se bild:

jag la också till '--sparse' som argument då det pressar 'luften' ur tex. diskimagefiler med stora områden med bara '0' i sig då områderna med bara '0' bara noteras i metadatat (och dessa '0' återgenereras senare vid läsning) utan att ta upp fysisk diskplats.

Sedan skulle jag verkligen rekommendera att använda BTRFS istället för ext4 på den nya lagringsdisken - finns några saker som inte går att vara utan när man väl har lärt sig....

1: komprimerande filsystem (aktiveras genom att skriva i terminal kommandot 'chattr +c mappnamn' på en mapp i BTRFS-filsystemet - alla filer som läggs i mappen och alla undermappar som sedan skapas kommer att komprimeras automatiskt i filsystemet (multicore-kompression) och utan att det syns (det går att välja komprimeringsalgoritm också - men är överkurs här)

2: att kunna göra nya kompletta kopior av subvolymer inom BTRFS-filsystemet med snapshot

dvs. en komplett kopia av en mappträd (som är en subvolym) utan att det tar upp mer plats på hårddisken - och det går på 1-2 sekunder även om mappträdet rymmer 10TB med data - och det kan sättas som read-only om man vill - dvs. inget i mappträdet kan ändras med vanliga filhanteringskommandon - inte ens tidsstämplar uppdateras inom trädet.

det görs i terminal med:

'btrfs su snap mapp1 mapp2' och mapp2 blir exakt lika som mapp1

subvolymerna som skapas är helt oberoende av varandra och som kan modifieras fritt sinsemellan och man kan ta nya snapshot ifrån dessa och även radera subvolymer i valfri ordning utan några beroende mellan dessa (till skillnad från zfs som är strikt hierarkisk), dock tar alla modifikationer som görs inom de olika subvolymer ny diskutrymme.

vill man göra det skrivskyddat:

'btrfs su snap -r mapp1 mapp2' och i mapp 2 fins inget som kan ändras - mappen själv går heller inte att radera utan att använda sig av btrfs-kommando.

Det är en utmärkt sätt att göra en kopia av sin gamla backup innan den synkas på nytt med tex. grsync - gör man bort sig eller filerna som kopieras över är krypterad av malware - så har du förra backuppgenerationens filer kvar oskadda i din skrivskyddade subvolym-kopia!!

"oj - jag har redan kopierat in en massa filer på volymen och ingen subvolym är skapad och jag kan inte göra en snapshot"

inga problem - ställ dig i roten på BTRFS-filsystemet, därefter

'btrfs su snap . mapp3'

mapp3 kommer bli en exakt kopia av hela disken/filsystemet _utom_ innehållet i andra redan existerade subvolymer (blir då tomma mappar i mappträdet)

och som redan sagt - en snapshot-kopia av en subvolym tar ingen extra diskplats (mer än typ 50 kByte eller så)

och som sista ordet för denna inlägg är att BTRFS fungerar väldigt bra tillsammans med SMR-diskar som typiskt de flesta externa USB-snurddiskar är.

inte? det är detta man exakt ser när man lägger tillbaka en diskimage med mycket data i... och blir lite jobbigt när det är 70 st som skall klonas/skrivas över.

Är det gammal data på diskarna och det har inte körts 'blkdiscard'¹ på hela lagringen en stund (strömmsatt!) innan så går det ännu 'ganska mycket' långsammare.

När man hanterar SSD/NVMe till och i från i jobbet så blir man rätt måttligt imponerad av SSD/NVMe av skrivprestandan efter att de har legat till sig en tid eller används en tid och inser i en del fall att de tom. presterar långsammare och mindre pålitligt än snurrdiskar när det gäller att skriva sekventiella dataströmmar utan avbrott som tex. när man spelar in från SDR-mottagare i ca 150 MB/s under många timmar - vilket hinns lätt med en större 3.5"-snurrdisk medans en Samsung T7 2TB-disk går bet på det i slutet - speciellt om man försöker den andra varvet när det redan finns gammal data på lagringen och det inte gjorts någon TRIM/unmap på hela utrymmet innan.

---

När man gör en sådan "Fill whole drive" - tester så borde det också göras på minnen som har till 80% fylld 2 år gammal skriven data i sig - det är då man ser den sanna farten med skrivhastigheten med ofta under 80 MB/s - dvs. långsammare än en laptop-snurrdisk och då inser man betydelsen i varför man skall göra 'blkdiscard' innan...

¹ linux program 'blkdiscard' så kan den skicka TRIM/unmap/discard (flera olika namn för samma funktion) för hela lagringen eller i adressebara block till lagringen utan hänsyn till något filsystem och är nog den enda metoden utöver 'zerofill' där man även kan ta början av lagringen med data som aldrig rörs annars.

Var var du någonstans år 2018 ??

Visst det har inte behövts så ofta de senaste åren som just 2018 där det var över 28 grader C i typ 3 veckor i sträck, dag som natt och man får komma ihåg att det är väldigt olika förutsättningar i olika lägenheter, hus och höghus och tex. lågenergihus med mycket isolering och mycket fönsterytor kan bli ordentligt varma på sommaren.

Lite för lätt - eller om man börja bli lite lastgammal... - och ja - jag har hanterat banankontakter (främst labbkabel)

Vill man flytta filerna (dvs. ta bort filen från källan när kopieringen har kvitterats klar) så kan man använda "--remove-source-files" i optionsraden. med parametern '-s' så gör den om stora och luftiga image-filer till sparse-filer (dvs. alla sektorblock helt fyllda med bara '0' noteras i filens metadata men tar inte upp någon fysisk diskyta - och vid läsning av filen återgenereras dessa nollor av filsystemet.

En sparsefil och en normal fil av samma fil har exakt samma hash-värde om man skulle prova att kolla det.

det fins ytterligare funktioner som att den läser filer från källmapp, jämför mot en referensmapp och av filerna i källmappen som det inte fins också i referensmappen - skrivs till en 3' mapp.

vill man verkligen kolla filer mellan mappar för tex. ta bort duplikat så kan man titta på 'rmlint' och den kan referar mot en 'master' mapp vars innehåll inte rörs i körningen.

rmlint tar inte bort några filer utan skapas en shellscript som gör jobbet när den senare startas separat och skriptet är smart nog att kolla om referensfilen fins kvar innan det tar bort dublett-filer - annars blir den kvar.

Min fysiska hp42s fyller 36 år konstaterade jag när jag räknade fram värdet på denna nyss.

På dator och nalle så installeras alltid free42 och görs som defaulträknare när det är möjligt.

För det flesta så är räknaren man använder under studierna som mer eller mindre följer resten av livet - eller tills den går sönder/förloras, och det är först då när man jagar en ersättare för det som man inser hur fastkörd man är på sin gamla räknares knappuppsättningar och funktioner och att en likadan som ersättare är ofta omöjlig att hitta och den nya man köper känner man motstånd att arbeta med då det inte går lika fort som innan och blir snart liggande i skrivbordslådan efter detta.

För min del var första miniräknaren lite för dålig för att bli en följeslagare - det var en programmerbar TI57 med LED och uppladdningsbar batteri och typ bara höll några få dagar innan det var tvunget att laddas igen - men det värsta var att den glömde allt så fort den stängdes av, även inslagna programmen. Ti59 med minnesremsor som kunde ladda in program var då en våt dröm som studentekonomin inte hade råd med... och hp-räknarna var långt förbi även de bättre TI-räknarna i pengar.

Några år in i början av yrkeslivet så köptes sagda hp42s och den har följt sedan dess och en key-faktor var att den aldrig glömde något som redan var inslaget i program eller register - och överlevde även batteribyte om den var avstängd under operationen och det inte tog för lång tid (fanns en lite elektrolyt-konding som försörjde RAM-minnet under operationen)

- och den absolut viktigaste 'egenskaper' som har använts även långt efter studentlivet var att den räknar numeriskt med komplexa tal sömfritt och utan speciallägen och på de allra flesta matematiska funktioner - vilket är himla viktigt när man höll på med transmissions-prylar och olika former av impedanser och matchningar men även inom elkraft som att räkna på faskompenseringar, förimpedanser med komplexa värden etc. - oj vad det hade underlättat om man hade den typen av räknare när man läste ellära och om växelströmskretsar under studenttiden. - just dennes komplex-värde hantering borde ha varit default på alla tekniska miniräknare riktat mot ingenjörer...

Windows 'dynamiska' pagefil växer bara - krymper inte igen när behovet är mindre - det är inte riktigt jag kallar dynamiskt, möjligen dynamiskt växande. För att bli av med filen (för att börja på ny kula) så måste man konfigurera den som ej använd - starta om och pagefilen försvinner - därefter aktivera den igen som 'dynamisk' och startvärde behöver inte vara så stort (typ 4 GB) då den växer upp filen igen när det behövs, har för mig att den inte behöver startas om igen när pagefilen aktiveras.

Nu vet inte hur mycket RAM du har i burken - men en pagefil på 36 GB i en win7 generation av windows är nog att betrakta som rätt stor och har växt av någon orsak. - har du någon idé vilken program som kan växa så mycket? (typ browser med väldigt många flikar uppe?)

Sedan som redan nämnt, 20 GB ledig utrymme på systemdisken är lite lite idag och en filsystem fylld till över 80% börja märkbart tappa prestanda, det oavsett snurrdisk/SSD/NVMe som används - den regeln gäller i stort sett alla filsystemstyper att när det är mindre med 20% diskutrymme kvar så börja det påverka prestandan.

Med tanke på hur lite ledigt som det är kvar så gissar jag att det är en SSD på typ 120 GB som systemdisk och det är lite med dagens mått även för en win7, 240 GB är nog en praktisk minimum lagring även om en nyinstallerad windows innan tyngre program är installerad och innan den börja tanka ned uppdateringar i bakgrunden kanske tar 28 - 35 GB i diskutrymme (delvis beroende på hur stor page-filen är).¹

¹ Är en siffra i bakhuvudet på fysisk storlek på qcow2 på linux-host med nyinstallerad windows när man har 'unmap' aktiverad och VM-imagen _är_ dynamisk växande och krympande i fysisk upptagen diskplats på värd-OS beroende på hur mycket filer klient-OS har i sig - dvs. VM-filen krymper när filer raderas inne i klient-OS då när windows raderar filer och den uppfattar sig vara på SSD eller på en SCSI-drive så skickas också 'unmap/TRIM' för den frigjorda diskytan och detta uppfattas av VM-värden och gör motsvarande 'punch holes' på sin vm-image fil och gör sparseblock på motsvarande ställe på vm-imagen och den fysiska platsupptaget på diskens yta minska även om vm-filens skenbara storlek inte ändras.

Virtual box har också motsvarande mekanismer (finns dock ingen knapp i GUI:t utan måste skrivas manuellt in i konfigurationsfilerna) att den kan känna av sända TRIM-kommandon från klient-OS och gör motsvarande 'punch holes' på sin VDI-image och gör sparse-segment för raderade filer i klient-OS

- men delen fungerar inte stabilt i windowsmiljö när jag provade sist och det kraschar efter en tids körning och det är oklart varför - en kraftig misstanke är NTFS-filsystemets begränsning i antal fragment för en fil och när det gör 'punch holes' på en fil så kommer det bli väldigt många fragment med tiden - därav att det blir problem först efter en tid då det är inget som varnar att det skulle vara ett problem för virtual box när VM-maskinen dras igång.

De flesta vettiga posixkompatibla filsystem - ja förutom NTFS - kan hantera nära på hur många filfragment som helst av en fil då det var en grundtanke i Unix-världen att filen fylls bara på data och tar upp diskutrymme först när sektorer faktiskt skrivs, och i valfri ordning över filstorleken - inte hur stor filen (skenbart) anges vara. Unix växte upp i en miljö där diskutrymme var dyrt och man skrev så lite som möjligt (vilket inkluderades dess metadata) och bara med valid data på de positioner som behövs.

(g)rsync kan du stoppa och starta igen - den kopierar inte över redan kopierade filer (bara nyare modifierade filer eller filer som ändrat storlek) utan efter lite sökningar i filträden först så fortsätter den där det slutade.

det som du troligen stött på är att din köpta disk är en SMR-disk (alla externa USB-snurrdiskar är SMR-diskar upp till 8, 10 och kanske 12 TB storlek - gränsen flyttas upp hela tiden) och även med ext4 som filsystem kan den köra i väggen och blir väldigt långsam - dock klarar den oftast typ 10 ggr mer småfiler innan det blir långsam gentemot om du hade kört NTFS.

BTRFS som filsystem fungerar rätt bra mot SMR-diskar och det är väldigt sällan att man kör så att den börja går i väggen.

När det händer och disken blir långsam - pausa eller avbryt kopieringen (rsync återtar ganska snabbt till platsen där den slutade sist när den har avbrutits) och låt disken får sköta sig själv minst en halvtimme - lite ytterligare tid om läshuvudrörelserna fortfarande pågår.

tja, om du känner att du måste slänga din hp42s så får du gärna maila mig innan det sker

Mer allvarligt, har du kika på vad de kan kosta som begagnade - de få som läggs ut alltså.

Gamla miniräknare - gärna byggda på slutet av 80-talet och med LCD-skärm så kan det gå årtionde mellan batteribytena.

Om man tittar på tomgångsförbrukningen i en hp42s så är tomgångsförbrukningen räknat över tid som mAh är något som räcker i typ 20-30 år på en batterisats, men problemet är att batterierna själva har svårt att hålla över 10 år innan de är självurladdade, medans har man en 'modern' HP miniräknare med CR2032 lithiumbatterier får man vara glad om den startar och har minnet kvar efter 3 år fast den legat i skrivbordslådan under hela den tiden.
Detta att bygga strömsnålt när det ligger i 'sleep' verkar man inte kunna längre...

luckybackup är ett backupprogram, inte en filsynkarprogram

det du vill ha är filsynkningsprogram mellan mappar.

har redan gett förslag med 'rsync' om man är bekväm med kommandorader i en terminalfönster. - 'rsync' är arbetshästen i linux/unix-världen när det gäller att hantera och synka mappar i olika backupprocesser inklusive att hämta/lämna filer via 'ssh' mot andra datorer över nätverk.

för typ ubuntu fins GUI-skal för rsync som kallas 'grsync' och kan installeras med "sudo apt install grsync" i en terminalfönster
jag själv har inte provat den då jag kör rsync i terminalförnster, men i princip väljer man en källa och sedan en destination och så kör den kopia på alla filer rekursivt som finns i den utpekade källmappen till mål-mappen och ser till att de är lika.

Har inte koll på just lucky backup men dessa brukar ha sina egna strukturer (repositorium) som inte ser ut som du är van vid.

hardcore users använder 'rsync' så fort det gäller att få två mappar eller diskar att bli lika.

ett typisk kommando i en terminal är 'rsync -avHP -i -i mapp/disk/att/kopiera/i/från map/disk/att/kopiera/till'

'-i -i' är för att man skall lite extra information medans det kopierar
'-s' kan man lägga till om man har typiska vm-images då det packas som sparsefiler (dvs. alla sektorer fyllda med '0' inom filen tar inte upp fysisk diskplats, bara bokförs i metadatat och de tomma sektorerna återgenereras senare vid läsning)

är man osäker i kommandot fungerar så provar man --dry-run som extra argument - dvs:

'rsync -avsHP -i -i --dry-run mapp/disk/att/kopiera/i/från map/disk/att/kopiera/till'

då gör den en torrkörning utan att göra något med filerna för att se att det ramla igenom på önskat sätt - speciellt om man har '--delete' och '--remove-source-files' med som argument i kommandoraden.

skriver man ls -lash så ser man i fillistans första kolumn i hur mycket filen tar i verklig diskplats - inte storleken den utger sig för.

på de nya disken skulle jag köra BTRFS av flera skäl:

1. du kan få komprimerande mappar, det kan du inte få i ext4

Man kan göra en mapp där allt som läggs i mappen komprimeras automatiskt genom att på mappen köra 'chattr +c mappnamn' och efter detta så alla filer som läggs i mappen, dess undermappar etc så komprimeras filerna automagiskt och utan att du ser det - det är multicore-kompression så det hinner lätt med marginal snurrdiskens skrivhastighet.

2. du kan göra kopia av befintliga subvolymer som är exakt likadana med snapshot utan att det tar extra plats och sedan kan modifieras individuellt eller kan sättas skrivskyddade i samband när snapshot görs - det är bara förändringar som görs som tar ny plats. en snapshot tar bara några få sekunder att göra även om du har 10 TB med data och en miljon filer i subvolymen.

3. allt är checksummat (det är default) och när man skapar volymen så är också metadatat också alltid i dubbel upplaga på lika ställen av disken. man kan koppla till diskar senare för att öka volymen logiskt (och även välja olika RAID-moder) och då kommer det automatisk att sprida metadatat till kopia på var sin fysisk disk.

Man skall ha väldigt rejäl dåligt dag om BTRFS inte repar sig efter fula urdrag och strömavbrott mitt under full skrivande - läs, det har aldrig hänt för mig hittills att BTRFS inte är accessbar efter sådan händelse - dock kan det ta lite tid efter en sådan händelse så man bör inte bli nervös om det kan ta minuter innan disken blir åtkomlig.

Du har väl redan räddat undan datat till en annan drive när du körde med windows eller ubuntu 20.04 innan du börja experimentera runt med disken med ubuntu 24.04 väl!?.

När det gäller data så så fins inget som heter 'hoppas' eller 'riskera' - man ser först till att det inte sker med tex backupper av datat på annan oberoende media innan man börja laja runt på en uppenbart påverkad/skadad filsystem.

NTFS är inget man skall ha som arkiv-filsystem - det är för vekt och bräckligt som tex. att man får strul efter att man råkat stänga av strömmen medans disken arbetar eller glapp på USB-sladden etc.

NTFS kan samla på sig märkliga fel utan att det upptäcks över tiden och när det blir påverkande fel som kanske ger avalanche-effekt på mer data helt plötsligt och det kan bli mycket krångligt att rädda ut datat felfritt. Ett av problemet med NTFS är att det fins inga checksummor någonstans i vare sig metadata eller vanlig data och så länge felen inte pekar utanför olika systemgränser så är det inget inom NTFS som märker det.

Använd ext4 eller hellre BTRFS för arkivhanteringen av data på externa USB-diskar och använd bara ExFAT/NTFS för att flytta data mellan olika OS när man inte vill strula med olika rättigheter och då bara med kopian av datat, inte orginalet.