ZFS prestanda vid kopiering av filer

vad är det för diskar i disk-seten (i avseende om du har SMR-diskar eller inte) - vilken sida trottlar (sändande eller mottagande sida) - med tex 'atop -fF 1' för du kunna se om diskar ligger på 100% last stora delar av tiden vid läsning eller mer troligt - skrivning. kolla sidan som leverera data och sidan som tar emot data och se vilka diskar som verka mest upptagna/lastade.

Jag brukar använda 'atop -fF 1' i en terminal för att se 'live' på sekundbasis. - maximera fönstret så kommer fler poster fram på olika saker i OS.

Om %b är belastningsgraden/väntkvoten på enheten så är det hyfsat lika på WD-diskarna som Seagate-diskarna - är det mycket knattrande och krossande ljudmässigt av läsarmsarbete på diskarna hela tiden?? ( blir så om det är småsektorer som skall jagas fram över diskytan för att bygga filer)

hur ser det ut i början när det går fort och senare när det flaskar - med slog och andra i ZFS använda cache-diskar - det kan vara dom som begränsar efter en viss skrivmängd om man använder billigare SSD med Cache-NAND.

jag vet när jag blandade SAS och SATA-diskar i samma mjukvaru-RAID så var det SATA-diskarna som drog ned prestandan till 1/4-del av vad det var när SAS-diskarna var ensamma - behövs så lite timing-avvikelser för att det skall dra ned hela RAID:en i prestanda...

med andra ord kan man och har råd (med SAS-HBA) - köp SAS-diskar, vilket var lektionen av övningen med att blanda SATA och SAS i samma mjukvaru-RAID för min del.

Notera att när du lägger in flera mirrored sets i en och samma pool så stripar ZFS över set:en. Dvs du har effektivt gjort en (motsvarande) RAID10-lösning.

Om du kopierar från "ett set till ett annat" som du beskriver så kommer sannolikt alla diskar läsas/skrivas ifrån. Det borde se annorlunda ut om du kopierar över nätverket till/från en lokal disk på din dator istället (vilket verkar stämma om jag förstår dig rätt). Kan det förklara det hela?

Bara för att dubbelkolla: du överför alltså från filservern -> workstation -> filserver? Isf är det inget märkligt att det ser ut som det gör i ditt scenario eftersom alla diskar ligger i samma pool. I början går det sannolikt snabbt för att cachen nyttjas, men sen behöver diskarna först läsa ut data och sedan ska data skrivas. Lite beroende på var datan ligger i set:en så kan ju hela skrivprocessen behöva pausas medans data läses och vice versa.

Det hade sannolikt sett rätt annorlunda ut om du splittat till två pooler istället och kopierat mellan dessa två. Dvs så att en pool enbart läser och en den andra poolen enbart skriver.

(EDIT: Jag hade undvikit att ha olika diskar i en stripad mirror-pool, eller ja egentligen hade jag nog skippat att ha olika diskar i en och samma pool oavsett konfiguration.)

Allright! Skönt att det fick sin förklaring och att allt verkar fungera som det borde ändå