Överföringshastighet mellan två WD Red Hårddiskar?

1: - använd helst inte NTFS och speciellt inte i samband med torrent-nedtankningar, men betyder i de flesta fallen att man inte kan använda windows som OS. Ärligt sagt har MS inget bra alternativ i filsystemväg om man inte vill och kan titta på ReFS.

2: att flytta filerna från en torrentfragmenterad mediafilarkiv till en ny disk är förmodligen den bästa defragmenteringsåtgärden man kan göra - även om måldisken som filerna kopieras till fortfarande är NTFS... - Det finns ingen genväg, tar det tid för att filerna är häftigt fragmenterade så får det ta den tiden som behövs för att röja upp i sörjan när det flyttas till ny disk.

3: om man skall bygga NAS/PLEX-server så bör man titta på alternativ på annan OS än windows, mycket för att man skall få fatt på bättre fungerande filsystem än NTFS - ext4 i linux är närmast skräddasydd (med lärdom av vad NTFS inte lyckas med) för att klara lastfall som torrentklienterna ger när man tankar filer.

Jag upplever dessutom att robocopy är snabbare än drag-släpp-kopiering i GUI:t. Vet inte varför, men det är en känsla jag har. Nu har jag inte kopierat mängder av TB mellan mekaniska diskar i samma burk, bara över nätverk, och ena gången var det nätverkståten som var flaskhalsen, i andra fallet var det en nas som kontrollerade integriteten på en nyskapad volym som var flaskhalsen. Skrivningen till volymen gick inte jättefort kan jag ju konstatera så här i efterhand.

drag-släpp-kopiering i GUI:t är förmodligen inte det bästa...

provat totalcommander eller liknande program? - en del går att krana i hur stora buffrar, disksynkningsvilkor mm. för att försöka få upp hastigheten lite till.

Dock ligger man fortfarande i windows subsystem och är filerna kraftigt fragmenterade så är dom det och det tar sin tid oavsett vad man försöker göra.

Jupp syftade på SMR, billigaste lagringsdiskarna man kan få tag på i dags läget.

Du bör läsa det "använd helst inte windows"

Det är av samma orsak som gör att flyttningen av filer från 4TB disken till 8TB-disken går så långsamt.

Det är bara att välja vilken pina du vill ha - att kopiera filerna från 4TB disken till 8 TB disken och det kanske tar hela dygn - eller att först defragmentera filerna under flera dygn och sedan kopiera filerna snabbare till 8TB disken betydligt snabbare (under ett dygn) - tid kommer att spenderas oavsett för att filerna är hårt fragmenterade....

Filerna som skrivs till 8 TB-disken blir dock hyffsat kontinuerliga (sammanhängande) med låg nivå av defragmentering.

---

Om jag skulle behålla 4TB disken med NTFS för senare användning så skulle jag efter flytt av _alla_ filer, formatera om 4TB disken med en nyskapad NTFS igen för att vara säker på att alla fragmenteringsbitar verkligen är borta (främst filerna som har legat i $MFT som inte säkert städats bort fast man tagit bort alla filer på disken då någon liten dold systemfil kan hålla kvar den sönderfragmenterade $MFT...

Om du efter detta provar att flytta tillbaka filerna från 8TB disken till 4 TB disken igen så kommer den överföringen med största sannolikhet att gå mycket fortare än tidigare och kanske nå runt 130 MB/s och högre.

I windows??

Har man server/enterprise version av Windows kanske man kan prova 'ReFS' - dock av någon anledning har denna dragits tillbaka av MS från de mer konsumentinriktade windows-versionerna (win8 Pro??) och finns bara i serverversioner och uppåt vilket innebär stödet för att läsa filsystemet blir i stort sett endast server-version av windows och det går inte att läsa av någon annan OS-miljö eller av home och Pro-versionerna av Windows.

mao. svårt med supporten den dagen när det skiter sig och ingen i Linux-världen kan hjälpa heller, då ingen spenderar tid på reverse enginering av en filsystem som ingen använder (ännu)...

---

Riktigt stora lagringssystem och SAN använder inte ens filsystem som vi är vana med utan det är key-value storage i en databas-liknande lagring och i en antal sådana poster tillsammans kan innehålla en hel iSCSI-volym som i sin tur är inkopplad till en OS med valfri filsystem. Tänk Amazon S3 och liknande...

Även moderna filsystem som btrfs och zfs (som körs i linux) arbetar med key-value storage i sin interna struktur mot shunks eller stripes på några hundra MB styck och lite av det såg man innan även på ext2 .. ext4 där man i volymen gjorde ett mycket stort antal 'minivolymer' (läs små partitioner) där varje öppnad fil fick sin egen 'minivolym' att skriva på och kunna allokera hela denna helt för sig själv under skrivningen vilket gjorde att vid många parallella filhämtningar som en torrentnedladdning så skrevs inte filbitarna efter varandra från sista föregående skrivna stället på disken från de olika pågående hämtningarna som i NTFS - utan varje fil fick sin egen 'minivolym' att härja fritt på och räckte den inte till i storlek så - kopplades en ytterligare 'minivolym' in och på så sätt minimerar man fragmenteringen av även stora filer när olika delar av filen hämtades ned i slumpmässig ordning som just sker med torrent-nedladdning.

kom ihåg att ext2 .. ext4 designades med lärdomar på vad NTFS gjorde dålig och rent av väldigt fel effektivitetsmässigt...

Filerna blir förvisso inte helt sammanhängande men kanske bara i tiotal stora stycken istället i kanske tiotusentals småbitar inflätade med andra småbitar av hämtningar på olika ställen som med NTFS.