Instabil extern disk

Jag använder Tixati, och där visas det om disken är överbelastad. Händer till exempel om jag laddar ned och kopierar eller packar upp något samtidigt på samma disk. Använder dock inga externa diskar.

I stort sett alla Seagate 2,5" diskar är SMR har jag för mig.

Du kan kolla in lite tips här:
https://appuals.com/utorrent-disk-overloaded/

Jag har tidigare ökat på disk cache och blivit av med överbelastning av hårddisken.

Jag har haft problem med en del externa hårddiskar som varierat i hastighet, det har då handlat om s.k SMR-diskar, och när man tankar torrents till dem, speciellt när de börjar bli fulla, blir diskarna helt överlastade. Och så har jag en Toshiba SMR-disk som funkar rätt bra till samma sak, har väl annan kontroller kanske antar jag. Om din disk är av SMR-typ vet jag inte, men jag misstänker det. Färre samtidiga nerladdningar har funkat bättre för mig.

Min disk funkar bättre med HFS+ som filsystem än NTFS, fast inte radikalt, är min upplevelse. En del externa levereras med ExFat som standardsystem, jag har inga erfarenheter av det.

Lösningen för mig var att jag gav bort min Seagate-disk (tror det var en liknande du har, fast 1TB) och tar nerladdningar till en annan disk (mindre, Seagate SSHD), och sedan läggs den färdiga nerladdningen över på Toshiba-"slödisken", som funkar utmärkt för läsning - det är när det ska skrivas mycket och osammanhängande i varierande hastighet och plats i filen som det blir riktigt knas.

Vad används för filsystem på diskarna - kan ni använda några Linux-världens filsystem som ext4 och hellre BTRFS (ZFS har jag inte koll på hur det hanterar SMR-diskar som ensamdisk mer än att i RAID-strukturer så är det mycket olyckligt val!) ??

NTFS är bland det värsta man kan välja på SMR-diskar (i stort sett alla externa USB-diskar sedan 2-3 år tillbaka under 8 TB för WD och Toshiba och 10 TB för Seagate är SMR-diskar - och det gäller både 2.5" och 3.5" oavsett fabrikat) och ännu mycket värre om det handlar om torrent-nedtagningar med flera parallella strömmar[1] samtidigt och kan gå riktigt illa även på rena PRM/CMR-diskar om man inte förallokerar filerna en och en till dess fulla storlek innan torrentprogrammen börja att ta hem segment.

NTFS på SMR-disk tar ofta stopp efter 15-30 GB med småfiler skrivna efter varandra, ext4 2-5 ggr fler filer än NTFS innan det går i väggen och BTRFS 10 ggr -> mot oändlighet (når inte väggen alls) även om man skriver TB-mängder med data i SMR-diskar. För stora sekventiella filskrivningar (som att flytta mediafiler från en SSD) klarar sig även SMR-diskar utmärkt i hastighet.

Kan man välja så skulle jag köra BTRFS på just externa USB-diskar, dels för att det är rätt tålig mot, eller snarare inte framkallar den situation med stallning som NTFS ganska snabbt kan framkalla med en knökfull media-cache[1] med en mycket ogynnsamma skrivmönster (bl.a uppdateras $MFT i NTFS med fysisk (alltså synkad fysisk) skrivning på samma ställe med lite olika data var gång 10 ggr per skriven/modifierad fil, medans linux gör det bara 1 gång, när den skriver mot NTFS-filsystem när den synkar mot disk-cache i RAM-minnet) och det går plötsligt mycket långsamt när cachen är proppfull och måste nödstäda för att sedan kunna ta emot en ny skrivning.

BTRFS har också mycket större tålighet och reparationsförmåga (och checksummar alla sina sektorer) om det blir glapp i USB-sladdar eller plötslig strömavbrott under nedtankningen för att det är transaktionshanterande och inte skriver över en redan skriven sektor (och därmed inte korrumperar sig själv med halvvägs genomförda skrivningar av tex. metadata) med nyss aktuell data utan alltid skriver uppdateringar/modifieringar på en ny sektor - detta gäller också diskens metadata när den bokför filerna (och därmed kan rulla tillbaka så lång det behövs för en konsistent startpunkt om disken har stängts på bryskt sätt), medans NTFS är att anses väldigt 'ömtålig' och lätt få permanenta och svårräddade filsystemskador vilket syns främst på i kombination med NTFS på externa USB-diskar medans det klarar sig bättre när diskarna används internt som lagringsdisk med SATA-anslutning och stängs i samband när OS stängs av.

[1] - skrivmönstret och fragmenteringen som blev vid flertal parallella skrivningar som torrentledladdningar där var och en av filerna skrivs fram och tillbaka slumpmässig ordning och är så illa hanterat i NTFS att man använde det som skolexempel i hur man _inte_ skulle skriva filsystem när man i linux-världen utvecklade ext3 och senare ext4 som filsystem. En del torrentprogram gör försök att minska fragmenteringen med att förallokera filerna med att skriva filerna till full storlek i förväg för att de skall hänga ihop sekventiellt och man modifierar sedan inom filen med lseek i skrivningarna, men på SMR-diskar hjälper inte det heller just att det inte skrivs i hela SMR-segment (sektorer) på 32-64 GB i stöten och inpassade mot SMR-zongränserna perfekt... filsystem som BTRFS börja ha stöd även för zon-skrivning tänkt för just SMR-diskar men problemet är att det går inte att fråga konsumentdiskarna av SMR-typ var zonerna ligger och dess storlek (som kan variera beroende på var över diskytan).

Idag är fragmenteringsnivåer på filer i ext4 sällan över 1% räknat på hela diskvolymen även om den används för torrent-nedtankningar.

BTRFS och ext4 har också smart allokering av data som försöker hålla ihop olika filströmmar i större separata sammanhängande block även om de skrivs i slumpmässig ordning och inte som i NTFS sektor för sektor som ramlar in och i skrivs likt journal i rad efter varandra på extension-delen av disken i samma ordning på disken efter varandra som blocken ramlar in och med flera parallella strömmar dessutom fläta in i varandra i ett zebramönster och blir väldigt långsamma att läsa sekventiellt senare när läshuvudet hoppar fram och tillbaka på disken för att få ut filen i sekventiell ordning igen.

BTRFS passar också in blocken som så bra som möjligt i lediga luckor på diskytan och har 'allocate on write' - dvs väntar så länge det går innan det bestämmer var datat skall skrivas på disken i förhoppning att så mycket data som möjligt hinner laddas ned, sorteras i rätt ordning och sedan delas upp i blockstorlekar efter mängden data för sekventiell läsning så snabbt som möjligt senare när det sedan skrivs, har tail-packing mfl. trix. Det har inte NTFS.

[2] media-cache skriven på diskytan längst ut i perferin finns i stort sett alla moderna snurrdiskar, och den kan vara ganska stor, upp till 70-80 GB och där läggs filer efter lite träning i den ordningen som de sedan läses vid tex. en tid efter strömpåslag för att tex. inläsning av OS och dess hjälpfiler (hibernate.sys mfl.) skall kunna läsas mer eller mindre sekventiellt så snabbt som möjligt även om adresseringen inom resp fil hoppar fram och tillbaka - en vidareutveckling av det är SSHD där man cachar läsordningen vid diskstart och en del av skrivningarna i flash för ännu snabbare läsföljd- men cachar också på den magnetiska ytan. Det gäller också PMR-diskar men då främst bara cachar läsordningen för filer som läses ofta i väldigt lika upprepande mönster.

Detta är något som nästan bara diskräddarna känner till då det i vissa sammanhang så kan denna synkning i cachen skita sig och då får man en disk som typiskt rapporterar några få GB fast disken är i TB-storlek i SMART och genom att stänga av cachen (genom diskens separata seriella service-ingång - om den inte är låst tillverkaren...) så kan man få tillbaka disken fulla storlek och mycket av användarens data igen - dock inte allt då en del kan försvinna i och med avstängningen av media-cachen.

Mekaniska diskar är dåliga på random access writes. Skaffa en SSD om du vill fixa problemet.

Mekaniska diskar har i minst ett decennium klarat av vad TS efterfrågar. Möjligtvis att lite tweakande, cache storlek, och filsystem påverkar. Men en mekanisk disk är definitivt kapabel till vad TS vill göra.

SMR-diskar är djävulens påfund. De är smarta nog att "optimera" sig själva, och skyffla om data, men det funkar (enligt mina erfarenheter) inte så bra på en disk som är igång och accessas typ 24/7. Det är säkert inte bra för diskar som börjar fallera heller, men det är en annan sak. (Jag har 2x6TB externa SMR-diskar för backup, de funkar bra för ändamålet)

Som exempel slänger jag in en bild från min externa hårddisk, med liknande användningsområde som TS. När jag väl sett hur landet låg kopierade jag över till en annan disk, det var enklast så.

Filsystemet här är HFS+ (Apple Mac), vilket är aningen bättre än NTFS gällande defragmentering. Det är dock _inte_ immunt mot problem.

Här ser man att filerna består av tusentals fragment. Jag har, på NTFS-diskar, haft filer i över 10 000 fragment. Det är ingen dröm på en SMR-disk. Om man förallokerar filer kan man få färre fragment, oftast, men ändå skrivningar till filen på många olika ställen "samtidigt". Det är inte heller någon dröm. Min Toshiba funkar som sagt märkligt bra, men låser sig ändå då och då, men har haft Seagate-diskar som hamnat på hastigheter under megabyten i skriv och då och då låser helt en stund i väntan på bättre tider

Skulle man någon gång fylla torrent-disken blir filerna rejält fragmenterade (får man räkna med).

Slänger bara in en bild till som är lite OT, men Apple-folk har ofta hävdat att Mac aldrig fått fragmenterade filer.

Här ser man att Iphotos databas över ansikten, exempelvis, har över 200 fragment, då den byggts på pö om pö och inte defragmenterats automatiskt (fel storlek eller nåt på filen). 500Mbyte ledigt på disken. Inga problem på SSD, men på snurrdiskar som Macar hade i många år var det ju såklart tråkigt att hårddisken rasslade en bra stund innan iphoto startade, eller när man bläddrade filer. (Jag har en SSD som Fusion Drive cache till min Ironwolf-disk med mina bilder på, det är en bra lösning)

testa ställa in så din torrent cachar mer RAM och därmed skriver större delar till HD i ett svep.. För många små skrivningar till disk kan sänka nedladdningshastighetten.

testa 8 GB, speciellt om du har snabb download så hinner den fylla RAM och börja cacha oftare och då hjälper det inte att cacha.

Testa även att öka intervallet som den skriver ner det cachade till disk. Minst 30 sekunder, gärna 1 minut.

JAg har 250 mbit men behöver ca 2 GB cache allokerat för att garantera att det inte blir problem.

Det skadar ju inte att laborera lite, du kan ju alltid ändra tillbaka sen

Slutligen, minska antalet klienter du laddar ner från. Flera hundra är inte nödvändigtvis bra:)

Men du skriver att hastigheten pendlar. Det är ju i torrents natur att beroende på vem du laddar ner från så kommer hastigheten att variera. Det kan inte vara det som är problemet?

Då är 8 GB ingen bra ide
Testa 4 GB kanske
Jag använder qBittorent, där går man på alternativ-avancerat, scrolla ner lite.
DiskCache, 2 GB och "interval för utgång av diskcache "30 s".

Enda är väl att välja en väldigt trafikerad torrent som har många klienter.

Om du vill mäta din internethastighet så finns ju andra verktyg än att ladda ner saker.
t.ex:
https://www.speedtest.net/

Jag har 250/250 internet och fick 268/268 när jag mätte hastigheten där nyss.
Men finns andra sidor som gör samma sak.

kom på en sak till som borde varit det första du testade:

Vad händer om du laddar ner till en intern hårddisk (förslagsvis SSD), får du bättre hastigheter då?

Prova med 4 GB om du inte har så mycket minne, 1 GB är nog lite lite i många sammanhang. ofta minskas cachen ändå i storlek om du har program med dataset som allokerar och låser en större mängd RAM.

Journal är ett problem både i NTFS och även i ext4 på SMR-diskar då det skriver runt i små duttar på begränsat ställe mest hela tiden och fyller sakta upp dess PMR-cache vilket gör att det inte kan sparas i stora svep som SMR-diskar önskar. - det gör att även ext4 slår i väggen vid kopiering av väldigt stora fil-set med småfiler men kanske tål 4 ggr mer småfiler än NTFS innan det sker. BTRFS är nästan att filsystemet i sig fungerar som en journal och har hela diskytan på sig att skriva sas. - därmed högre till tak innan begränsningar/full skriven PMR-cache på SMR-disken.

Annars är att köpa en skitbillig SSD på 250-500 GB som du kör ned dina torrent på (tills den är trasig) och sedan flytta filerna till din magnetiska lagring - då blir det att vid kopiering läses filerna ut sekventiellt även om det är stökigt och fragmenterat skriven på SSD och sedan skrivs sekventiellt på SMR-disken och i dom lägena fungerar SMR-disken rätt bra då den har inga problem att skriva många stora filer efter varandra.

Om jag förstår TS så är det MacOS han kör, det är ännu känsligare än Windows för om disken går full. Jag fick återställa från Timemachinebackup (hel omformattering av systemdisken) efter att ett vildsint program allokerat varenda byte på hårddisken varpå många andra program och systeminställningar gick bananas. Har man 128GB rekommenderar jag nog att man lyfter över lite på icloud om det inte redan är gjort. Jag betalar 9kr/månad för 50GByte, det räcker en bit + att icloud är så slött att man inte vill ha för mycket där.

En ful-lösning kan vara att köpa ett endurance-klassat SD-kort (eller micro-sd i medföljande adapter) på Amazon för ett par hundra, sätta in det i datorn och ladda dit för att sedan flytta till hårddisken. Inget att köra med i flera år, SSD håller säkert bättre, men det är en snabb och ganska billig lösning som inte tar plats på skrivbordet. Tror TS dator har kortläsare som klarar rätt bra fart.
Typ https://www.amazon.se/-/en/dp/B07NY23WBG/ref=sr_1_5?crid=4MRG... eller https://www.amazon.se/-/en/dp/B07CYF9SH5/ref=sr_1_3?crid=33YM... (snabbare tror jag)

Jag skulle dock inte köra på SD eller micro-SD då de har inte någon wearlevling att hänga i julgranen, trottlar fort vid längre skrivsessioner (överhettning av den lilla chipet vid skrivning) och har ofta usel 4K- skriv kapacitet, och dessutom om man skall ha 128 GB och större börja bli väldigt dyra - dyrare än riktiga SSD-diskar om det inte är wish-modeller typ med 512 GB lovade och i bästa fall 16 GB fungerande...

Bättre motsvarande som Samsung T7 eller om man hittar motsvarande billigare (Sandisk USB-SSD är faktiskt betydligt dyrare för samma storlek) som har en riktig SSD/NVMe-kontroller i sig till skillnad från de som finns i SD/micro-SD eller USB-stickor av 'extrem'-modell (alla andra som har lägre prestanda än motsvarande 'extrem pro' kan man strunta i då de har samma svagheter som SD-minnen med mycket dålig wearlevling samt kvaliteten på flashen är oftast i underkant redan från början)

Oavsett vilken flash-lagring - dessa är inte tåliga mot långtidslagring utan att kopplas till spänning då och då och kanske läsa igenom minnet (dvs. 'scrub' för att detektera celler med laddningen i underkant och ger mycket RAW bitfel vid läsning och programmeras om till bättre kvalitet igen, SSD gör förmodligen det själv efter ett tag men kan startas senare och ta längre tid, vilket inte hinns med om man bara pluggar i - överför det man skall och sedan kopplar ut i en 5-10 minuters session) då de är för det mesta numera av QLC-typ.

För långtidslagring/arkiv - använd mekaniska snurrdiskar!! (dock helst inte med heliumfyllnad om de inte kommer att röras på flera år i sträck vilket innebär 8TB och mindre diskar som är luftfyllda och att de då är av SMR-typ för det mesta) och med viktig data har kopior på flera olika oberoende media.

---

Nackdelen med extern SSD via USB är att 'TRIM' fungerar inte när det inte är AHCI-gränssnitt (läs disken ansluten via SATA-portar direkt) och OS med filsystem kan inte berätta för SSD-lagringen vilka sektorer som nu inte längre bär data och disken själv kan stuva om internt för lägre wearlevling och snabbare skrivning senare - för en QLC-SSD disk är det inte helt oväsentligt då den använder kvarvarande ej med data skrivna lediga utrymme som SLC-cache som senare packas tätare till 4 bit/cell när det har lite lugn och ro och frigör plats för SLC-cachen igen som efter operationen är lite mindre i storlek då en del av dess utrymme lagrar nu valid data - är det inget som berättar vilka sektorer som inte innehåller data när disken väl har varit fullskriven en gång så är dess SLC-cache liten (typ 10 GB på en 500 GB-disk) och dess prestanda kommer att påverkas.

Dock finns det kanske lösning - har dock inte kollat på just Samsung T7 då denna jag har redan sitter fast i en applikation - Samsung T7 redovisar sig själv som en SCSI-disk - och precis som iSCSI över nätverk mm. så finns begreppet 'unmap' - vilket har den fascinerande verkan på en iSCSI-enhet på tex. en NAS att raderar man filer i tex windows på en i windows inmappad disk via iSCSI (och då kallar på TRIM när filer raderas, förutom att windows kör TRIM på tid då och då på all ledig diskytrymme i filsystemet ändå) så minskar storleken i upptagen diskutrymme på den fysiska disk-imagen på NAS:en med att via olika vägar använda motsvarande funktionen "fallocate --punch-hole --offset xx --length yy /sökväg/diskimage" (även olika VM-maskiner gör det på sina diskimages) och den vägen av-allokerar sektorerna och återvinns som ledig plats i Nasen och disk-image blir då av 'sparse' typ där områden som inte innehåller data (läs bara binär '0') - just emuleras som sektorer som är fyllda med binär '0' om man läser filen utan att det går ut på disken fysiskt. Apparanta storleken (skenbara storleken) kan var 250 GB men fysiskt på disken bara drar 5GB om iSCSI-enheten är nygjord och nyformaterad innan man fyllt på filer eller är tömd på tidigare filer.

'unmap' är helt nödvändig funktion för att återlämna plats för tex. olika SAN som till sin största del just exporterar iSCSI-volymer till olika datorer och VM-maskiner över nätverk.

just denna funktion med 'unmap' verkar också finnas på externa NVMe SSD via USB om den har implementerat USAP (USB attached SCSI Protocol) korrekt

då kan man prova (i Linux):

https://www.glump.net/howto/desktop/enable-trim-on-an-externa...

Jag har inte själv gjort det ännu - så jag kan inte svara om Samsung T7 fungerar med 'TRIM' (fstrim) efter detta - men skall man ladda ned mycket torrent som skriver filerna i alla möjliga ordningsföljder (då använder man helst ext4 som filsystem då den är i princip skriven för den typen av användning - kanske bättre än någon annan typ av filsystem för just torrentnedtagningar) och man sedan flyttar undan de färdiga filerna så bör 'fstrim' köras på kalender eller manuellt efter färdiga filerna är flyttade till annan lagring just för att få de 'upptagna sektorerna' att bli friställda och SSD-kontrollern kan göra SLC-cache av dessa igen och därmed snabbare hantering och mer jämn slitage av flash-minne.

Varför Linux traditionellt inte kör fstrim när man tar bort filer på samma sätt som windows gör i bakgrunden (dock kan man slå på det som parameter vid montering av filsystemet) är en filosofi där körningen av TRIM kan få SSD att stalla mer eller mindre korta tider - framför allt på äldre SSD som kunde försvinna i flera sekunder och därför avråder man från det av helt enkelt som resultat av praktisk användaråterkoppling där ryck och stall i vid läsning/skrivning mot lagringen ger problem i serversammanhang.

Om QLC-flashminne (oavsett om det är som extern disk eller intern NVMe-disk) skall köras i Apple och MAC-miljö liksom Windows så beror det mycket på om och vilka medföljade drivrutiner som installeras om TRIM-funktionen fungerar eller inte över USB eller mot intern NVMe - default fungerar det inte över USB med i OS använda standard USB-drivisar utan behöver extra drivrutinhjälp ofta från tillverkaren!

- Men skall man köra ned mycket Torrent bör man ha fungerande TRIM-funktion - speciellt efter om du kört disken stumfylld någon gång alternativt ha en rejäl överprovisionering satt redan innan. För en SSD är alla skrivna sektorer giltiga tills sektorn skrivs över med ny data eller med TRIM/unmap säger att de inte används. - det är trim/unmap som används i adressområdet på den frigjorda ytan (ändrad med att disken partioneras om till mindre volymer och filsystemet skalas ned ) oftast i slutet av disken som kallas överprovisionering - det är först efter trim/unmap (eller skrivit området med binär '0') som frigjorda områdets flashminne kan användas för diskens interna SLC-cache .