Diskussion: Den stora NAS-tråden - tråden för NAS, mediaserver och dylikt

Det ska inte påverka din cache-hastighet alls.
Write method handlar om hur den skriver och läser parity.

Jag har xfs på array och zfs på cache.

Men det är ju mycket konstigt om den visar 100 där och 50 över nätverket. Om den inte skriver från ram dvs.

 

Vet inte om det spelar så stor roll..

Sätt din cache-share så den flyttar cache -> array och sen kör du mover (du lär redan ha det så) . När allt är klart så kan du sätta array som primary för den sharen och ingen secondary. När disken är formaterad och tillbaka ändrar du samma share så den flyttar array -> cache igen och kör mover. Sen ändrar du tillbaka som du vill ha det (cache-array). Se till att docker och VM-tjänsten är stoppad under tiden. Detta behöver göras för alla shares som har data på cache.

 

Nej, det där kan vara som det är.
Jag ser att en av dina diskar sover så den använder inte reconstruct write på din screenshot. Kolla om det gör skillnad.
Du kan väcka och söva genom att klicka på gröna/grå plupparna.

 

Du kan ändra när som helst. Även samtidigt som filer flyttas.

 

Blev det någon skillnad?
Svårt att säga. Jag kör ju ZFS men jag har två diskar i mirror. Brukar säga ZFS. En del tycker ju att ECC ram KRÄVS för ZFS, andra inte. Jag tror inte att det är någon fara. Unraid sätter också ZFS cachen till att max använda 1/8 av RAM när den behöver. Det går att ställa själv men bara via config-fil än så länge. ZFS på enskilda diskar ger inte fördelarna som ZFS har, som att upptäcka trasiga filer osv. Då behövs minst två diskar men om man har planer på att lägga till någon disk i framtiden så kan man ju köra ZFS ändå. Btrfs har jag väldigt lite erfarenhet av men det var en del trubbel med btrfs när jag började.

Jag har en "slaskdisk" ensam i en pool, där kör jag XFS men det är data som kan försvinna när som helst utan att det gör något. Men XFS är väldigt stabilt men inte så modernt jämfört med btrfs och zfs. XFS var väl mer inriktad på media och databaser m.m. från början. Stora filer. Inte många små men nu för tiden ska det inte vara några större problem.

 

Ja, det är vad reconstruct write gör. Den läser från alla diskar samtidigt för att räkna ut parity.
Då slipper den extra steg och läser inte aktuell parity bit från parity, den bara skriver en gång. Här är en wall of text om du vill veta mer:
https://forums.unraid.net/topic/50397-turbo-write/

Btrfs borde ändå funka. Tror kanske inte att det kommer göra någon större skillnad. Det är någon annan flaskhals någonstans är min misstanke. Hmm.

 

Kan nog finnas en nackdel i reconstruct write också (utöver den ökade strömförbrukningen men jag kör pluginet så den bara kör reconstruct write när alla diskar ändå är igång), den läser från alla diskar så den blir begränsad till den långsammaste disken men de brukar ju ändå vara rätt snabba på läsning. Samma med parity, snabbaste och största disken som parity så vi inte väntar på läsning och skrivning till parity i onödan. När jag har utökat med fler diskar har jag flyttat den gamla parity till en data och gjort den nya disken till en ny och fräsch parity.

 

Förresten. För alla som kör Unraid. Den fil du anger under Docker settings (jag kör katalog, inte fil) så gör det typ ingenting om den stora filen eller katalogen råkar försvinna (appdata ska man dock vara försiktig med). Man kan återskapa varje container en och en via Docker-tabben och "New container" så finns din gamla med i listan där så kan man återskapa den enkelt. Config ligger på USB-stickan och appdatan där du har lagt den. Via Apps kan man ta "Previous apps" och klicka i alla containers man hade innan så lägger den tillbaka alla dina containers som de var med samma inställningar som du hade i templaten. Allt sparas i xml-filer på USB-stickan. Ta backup på den löpande. Med Unraid Connect görs backup till deras servrar.

Så, man behöver inte ha någon backup på docker img-filen. Jag kör katalog för då allokerar den inget utrymme för img-filen. Med docker directory och overlay2 som storage driver så tar den bara upp den plats som faktiskt används av docker-motorn. Se till att det är på cache/pool only dock. Docker img eller folder på array gör det långsamt. Har du en docker.img så tar den alltid upp max storlek som man sätter den filen till, även om man inte använder hela utrymmet eller tar bort containrar. Jag behöver inte heller öka någon img-storlek om den börjar bli full. Skapa en share som heter typ docker, sätt ssd pool som primary, ingen secondary, ha exclusive access aktiverat Settings-Global Share Settings-Permit exclusive shares, sätt /mnt/user/docker som dir location.



OBS. Min docker dir och storage location har "Exclusive access" (cache only) så den bypassar FUSE.
Därför är mina sökvägar under /mnt/user istället för direkt till /mnt/poolnamn för att det blir samma sak med exclusive access. Det gör också så att jag skulle kunna flytta min share "docker" och "appdata" mellan diskar, array, pools osv utan att sökvägarna ändras.

Docker dir kan jag förlora när som helst utan att det gör någon skada. Lätt att återskapa. Default appdata är dock helig, på speglade SSDs (samma som share "docker") och har regelbunden backup.

 

Testade unraid igen, men fortfarande markant långsammare än andra nas mjukvaror. Speciellt samtidig läsning till en pool och skrivning till en annan dödar hastigheten. Känns som en bug eller nått.