Hårddisk för torrents

Borde funka med vilken disk som helst hastighetsmässigt då det inte är hastigheten som är ett problem utan fragmentering och den drabbas alla av oavsett hastigheten om du fyller dem för mycket och inte föralllokerar hela utrymmet för respektive fil.
Vill du minska risken att fragmentering påverkar så skaffa en ssd om det ändå inte är nån större enhet än 1 Tbyte du vill ha.
ssd påverkas också av fragmentering men inte vid läsning utan vid skrivning och mest om de gått väldigt fulla ett längre tag så trim och diskopimering inte kunnat hålla efter dem på ett bra sätt.

Är de skadade sektorerna av "pending"-typ så är det mjuka fel och vid nästa överskrivning av sektorn i fråga så försvinner dem med största sannolikhet - varför dessa kan bli är tex om man knuffar disken eller pga. vibrationer eller annat mitt just under skrivning. Har du reallokerade sektorer i din SMART så är det däremot 'hårda fel' och när de börja blir fler på kort tid (ett antal i veckan) så är det dags för ny disk medans ökar det med enstaka i månaden och färre så är det inte lika bråttom.

Största problemet för dig är att du använder Windows och filsystemet NTFS i samband med torrentnedlagringen - och så länge du envisas med det så kommer problemet att fortsätta utan någon framtid till förbättring. Det enda du kan göra för att få det tillfälligt att gå fortare är att köra defragmentering ofta (men kommer ta tid i sig för att trassla ut alla sektorer fram och tillbaka på varje fil) och ibland går det snabbare att ta ut alla filerna till annan media - ta bort partitionen, skapa partitionen igen med en ny NTFS och sedan lägga tillbaka filerna... - Detta för att en välanvänd NTFS får en stor $MFT där olika filstycken göms och de flesta gratis-defraggprogram rör inte just $MFT av anledningen att $MFT är själva filsystemet med sin metadata men också flätar in delar och hela filer i sig och i sin filkropp (speciellt om disken körs med mer än 75% full) och sökningen inom denna filkropp är långsam som få.

Stöder din torrentklient att förallokera filen i hela sin storlek innan den börja ladda ned filen i fråga så kan du spara en del på disken när det gäller fragmentering av filen och kan komma undan att defragmentera NTFS mer sällan, dock kommer inte behovet att försvinna helt...

Att använda andra filsystem som VFAT, eFAT etc. gör det ännu mer långsammare och läget är helt enkelt krasst att MS har inga bra filsystem för sitt OS att välja mellan och den 'moderna' filsystemet som skulle kunna vara aktuellt här - "ReFS" finns inte på annat än OS ovanför pro-serien av windows.

Torrentköning med NTFS kan tom. göra att SSD blir långsamma (förutom snabb slitage de medför om det är mycket skrivning av nya filer) för att filerna hackas upp i tiotusentals små bitar som sprids över hela disken och delar av dem flätas in i $MFT där var och en behöver anropas för att ta tillbaka dessa och även om SSD har låg söktid så blir det mycket även där för >10000 anrop för en fil istället för några hundra i större stycken - så illa är det, NTFS är en skitfilsystem från 1990-talet som alla har vuxit ur och alla andra stora OS har bytt filsystem både 1 och 2 gånger med bättre optimering för nya skriv och sökmönster under åren, men inte MS som bara plåstrar lite lamt då och då...

---

Alternativ att titta på är att köra sina torrent på annan plattorm än under windows - filsystemet ext4 i linux är i stort sett skräddarsydd för torrentkörningar på snurrdisk (på allvar! - utvecklarna tittade nämligen på vad och varför allt gick så fel med NTFS vid torrentkörningar och försökte så mycket det gick undvika att upprepa misstagen MS gjorde) och det skulle inte förvåna mig att man kan göra en lösning med en rasperry PI mot en extern USB-disk med ext4 som filsystem och tugga torrents utan knot.

Ytterligare att titta på är att din torrent-klient lägger filerna på en nätverksvolym direkt på en NAS då alla köpenas använder ext4 eller BTRFS som filsystem på sina diskar och lägger dem mycket smartare än NTFS någonsin kommer att lyckas med.

Vad det handlar om vid torrent är att hitta alla tänkbara lösningar som i slutändan inte ligger på en NTFS som filsystem - för med NTFS så blir det bara skit efter en tid!!.

Köp heller inte för liten disk när du köper en ny disk - filsystem gillar inte när diskarna är mer än max 75-80% fyllda (och speciellt inte NTFS) och vill ha armbågsrum för att placera ut sina filer med lucka mellan dem så att de kan växa åt båda hållen utan hacka upp filerna i småbitar när de sedan växer efter hand (typisk torrent-mönster där man skriver ned olika bitar av filen i slumpmässig ordning och utan given slutstorlek till en början), tvingar man att köra med mer än 90% fyllnadsgrad så börja det bli jobbigt för de flesta filsystemen då de tvingas att hacka upp filerna i mindre bitar för att fylla småhålen som är kvar och i det här läget och bit innan dess så börja NTFS att skarva på sin $MFT och lägga filer och filbitar inom $MFT-filkropp vilket drar ned hastigheten fatalt...

'lågnivåformatering' använder sig av disken egna interna test-rutiner (den stora) och kan mycket väl ta bort dina pendings sektor. men det är inte det som är problemet utan för att du använder NTFS som filsystem på disken.

Viktigaste momentet för dig är att ta ur alla filer (går det väldigt långsamt att kopiera ur filerna och disken rasslar som en tok under tiden, så beror det på att de är väldigt fragmenterade), ta bort partitionen och sedan skapa en ny NTFS-partition, lägga tillbaka filerna - bara den momentet kommer göra din disk flera gånger snabbare - detta kanske måste upprepas va 6' månad och med diskdefragmentering 1 ggr i veckan om du kör med torrent intensivt på disken - och som sagt, se till att torrentklienten förallokera nya filerna till sin fulla storlek innan den börja ladda ned ny data så kanske din disk håller sig snabbare i längre tid.

Största möjliga kluster storlek skall du välja.
Det innebär mindre fragmentering av disken.

För en disk avsedd för att installera OS (Windows) på, sparar man plats med mindre kluster storlek. Men för att lagra stora filer, är det bättre med stora kluster.
En text fil på 1kb, tar upp hela klustret. Har du ställt in 64kb, tappar du alltså minst 64kb för var enda fil.
Men med stora filer spelar det väldigt liten roll vad gäller oanvänt utrymme.
Där emot får du med 64kb, mindre antal kluster och disken blir därför inte lika fragmenterad.

Jag har själv en tillsynes frisk disk som uppvisar samma fenomen vid torrenting, men jag misstänker snarare att det beror på att diskens I/O blir överbelastad.
Om jag seedar och kör igång en ny torrent, så trycker write-ops:en ner read-ops:en på disken, vilket medför att min uppladdningshastighet sjunker (se graf nedan).

Lösningen är i så fall antingen en disk som klarar fler IOPS, eller fler diskar att sprida ut datan över.

Du har en 'budget' ca 350 sökningar i sekunden (ca 2.8 ms per sökning i genomsnitt - inget att klaga på för en snurrdisk) och om man ser i slutet på diagrammet så är det ungefär lika mycket sammantaget när man räknar ihop alla läs och skivsökningar även i fallet när du börja ladda ned.

Det man kan undra/fråga är om inte en bättre optimerad disk-cache i RAM-minne hade kunnat få ned många av dessa sökningar - dvs läsa/skriva färre men större block. och som redan nämnt så är inte SSD en given lösning i dessa situationer då slitaget på dem kan bli stort.

det skulle vara intressant och se en i mesta möjligt kopierad driftfall men körd under linux och på ext4-disk och BTRFS-disk och se om och hur mycket skillnad det är.

Det är från FreeNAS, ett NAS-OS.
Jag kör sedan Transmission (torrent-klienten) som ett plugin/jail direkt i FreeNAS.

Observera att jag inte är TS, jag bara inflikade då jag upplever samma fenomen.

Jag tror att nästan alla Torrent-klienter har någon form av RAM-cache för skrivningar inbyggd.
I Transmission som jag kör finns det en parameter för hur många MB som cachas i RAM per peer som man laddar ner ifrån.
Som standard står den på 4MB, men jag har provat att öka den till 8MB utan att märka någon skillnad.
Laddar jag ner från 50 peers är det alltså 8x50, d.v.s. 400MB som cachas i RAM innan det skrivs till disken.

RAM-cache för läsning blir nog svårt, eftersom att du på förhand inte vet vilken del av vilken fil som kommer att efterfrågas.

Jag kör FreeNAS, så det är ZFS som gäller för min del.
Jag har bara en random skräpdisk i burken för tillfället, men kommer gå över till 4x4TB NAS-diskar i troligtvis raidz-1, så det lär ju i alla fall bli bättre då.