Alternativ för "NAS" för USB-C diskar?
Botaniserad marknaden lite för att hitta en mojäng för att kunna dela ut ett par externa USB-C hårddiskar i hemmanätverket, men gått bet...
Det finns rena NAS lösningar förstås, och vissa routers har möjligheten, men inte min UniFi router.
Just nu lutar jag åt en RaspberryPi som får agera "file server" men det känns ju lite "meckigt" att behöva låta en RPi stå och tugga...
Alternativ?
Det finns rena NAS lösningar förstås, och vissa routers har möjligheten, men inte min UniFi router.
Just nu lutar jag åt en RaspberryPi som får agera "file server" men det känns ju lite "meckigt" att behöva låta en RPi stå och tugga...
Alternativ?
Självbyggare
· Stockholm
· 8 227 inlägg
Använda en "gammal oanvänd dator" med tillräckligt många externa portar (eller en dock/port-duplikator) och dela ut access via den?anders07 skrev:
Är kanske inte mindre mecikgt än en raspberry som så, men om du ändå har en liggandes så...
Alternativen beror ju på din budget. Spontant skulle jag säga att du borde köpa en begagnad minidator för några hundralappar och installera antingen Windows eller en Linuxdistribution anpassad för NAS-bruk på den och så bara ansluta dina hårddiskar den vägen. Är ju inte vidare meckigt och drar inte överdrivet mycket ström. Går ju även tänka sig att den går ner i energisparläge efter någon timme men kan väckas genom wake-on-lan.ternativ?
Diversearbetare
· Göteborg
· 10 705 inlägg
Håller med. Billigare än en RPi kommer man inte undan om man inte har en gammal Intel NUC eller liknande strömsnål dator. Dessa Intel-baserade kan köra Truenas Scale eller Unraid som OS och det går utmärkt att dela ut USB-diskar. RPi kan köra OpenMediaVault.useless skrev:
Läste på lite och tydligen kan en RPi som kör som "NAS" ha det lite jobbigt och bli varm så det rekommenderas fläktar... Det finns ju "skal" för RPi med fläktar och den kommer att stå inne i en garderob med routern.
OpenMediaVault verkar ju trevligt, så helt klart ett intressant alternativ då!
OpenMediaVault verkar ju trevligt, så helt klart ett intressant alternativ då!
Diversearbetare
· Göteborg
· 10 705 inlägg
TS skrev:L lat skrev:
Ofta klarar router bara en enda disk och dessutom långsamma som sjuttsingen i USB2-takt i överföringshastighet
Välj inte en NAS-lösning som använder sig ZFS som filsystem i (som TrueNas gör) när man kopplar in lagringen i form av USB-diskar, utan basera NAS-lösningen på ext4 eller (hellre) BTRFS.
---
Varför ZFS som TrueNAS avråds å det bestämdaste när man kör mot USB-snurrdiskar och dess allt för ofta innehållande SMR-diskar beror på grundproblemet med 8 sekunder 'kickout tid' av diskar som ställer till en massa trassel och kanske totala dataförluster
dvs. diskar som inte svarar inom 8 sekunder kastas ut och det kan ge massor av problem om de ingår i olika RAID-strukturer och ofta total filsystemshaveri när en disk för mycket i Raiden kickas ut kort efter varandra.
Det var det som köpare av WD-RED diskar råkade ut för när WD smyginförde SMR-diskar på WD-RED för NAS utan att tala om för köparna och det blev omfattande haverier bland ZFS-användare med totalförluster av data.
Det är två problem med USB-diskar som ZFS inte räknar med och heller inte hanterar bra.
1: USB-kabinettet kan själv få för sig att stänga av spindelmotorn på disken under användning efter en stunds inaktivitet - och för stora diskar med många skivor kan uppstartstiden igen vara mer än 8 sekunder innan disken varvat upp och svarar över USB igen och då har ZFS redan kickat ut disken.
2: Den andra och minst lika stora problemet är att alla 3.5" USB-snurrdiskar som är 10 TB och mindre är SMR-diskar, kanske från 12 och 14 TB och mindre idag, samt alla 2.5" USB-snurrdiskar senaste 5-7 åren också är SMR-diskar.
På SMR-diskar mellanlagras småskrivningar som inte kan placeras direkt kant i kant på en SMR-segment @ 32-128 MB-stor i en skrivkö i PMR-buffert på disken, som städas ned till noll när disken har ledig tid - problemet är ofta när stora mängder småfiler skrivs så blir denna PMR-buffert full fort trots att den kan vara från 30 - 70 GB stor och disken måste börja nödstäda för att få plats för nya skrivningar och under den tiden detta pågår så svarar inte disken på förfrågningar av systemet utan disken upplevs vara responslös och när detta sker i längre tid än 8 sekunder så tolkar ZFS disken som trasig och den kickas ut - och detta vet man inte när det händer utan kan ske precis när som helst.
Dock ofta när väldigt mycket filer har skrivits eller under processer som när RAID synkas upp ('resilver' på ZFS-språk) och läses konstant och med typ var tredje eller var fjärde block skriver data (paritetsdatan) mot disken konstant hela tiden i timmar utan avbrott - vilket på SMR-diskar direkt fyller upp PMR-delen då blocken som skrivs är mycket mindre än SMR-segment och när PMR-delen är full så börja den stalla, för att disken måste nödstäda och ofta utan respons i mer än 8 sekunder.
---
SMR-diskar och SSD/NVMe-minnen av billigare sort (som QLC-minnen med SLC-cache av begränsad storlek) har väldigt liknande beteende när deras SLC-cache-minnen eller PMR-buffert har förbrukats upp av massa skrivningar på kort tid och går jämförelsvis väldigt långsam gentemot deras ordinarie hastigheter - med skillnaden att SSD/NVMe svarar inom delar av sekunder även i det läget (undantaget att när SSD gör TRIM så kan det vara borta i åtskilliga sekunder utan respons) medans SMR-disk kan vara borta längre än 8 sekunder innan respons.
Välj inte en NAS-lösning som använder sig ZFS som filsystem i (som TrueNas gör) när man kopplar in lagringen i form av USB-diskar, utan basera NAS-lösningen på ext4 eller (hellre) BTRFS.
---
Varför ZFS som TrueNAS avråds å det bestämdaste när man kör mot USB-snurrdiskar och dess allt för ofta innehållande SMR-diskar beror på grundproblemet med 8 sekunder 'kickout tid' av diskar som ställer till en massa trassel och kanske totala dataförluster
dvs. diskar som inte svarar inom 8 sekunder kastas ut och det kan ge massor av problem om de ingår i olika RAID-strukturer och ofta total filsystemshaveri när en disk för mycket i Raiden kickas ut kort efter varandra.
Det var det som köpare av WD-RED diskar råkade ut för när WD smyginförde SMR-diskar på WD-RED för NAS utan att tala om för köparna och det blev omfattande haverier bland ZFS-användare med totalförluster av data.
Det är två problem med USB-diskar som ZFS inte räknar med och heller inte hanterar bra.
1: USB-kabinettet kan själv få för sig att stänga av spindelmotorn på disken under användning efter en stunds inaktivitet - och för stora diskar med många skivor kan uppstartstiden igen vara mer än 8 sekunder innan disken varvat upp och svarar över USB igen och då har ZFS redan kickat ut disken.
2: Den andra och minst lika stora problemet är att alla 3.5" USB-snurrdiskar som är 10 TB och mindre är SMR-diskar, kanske från 12 och 14 TB och mindre idag, samt alla 2.5" USB-snurrdiskar senaste 5-7 åren också är SMR-diskar.
På SMR-diskar mellanlagras småskrivningar som inte kan placeras direkt kant i kant på en SMR-segment @ 32-128 MB-stor i en skrivkö i PMR-buffert på disken, som städas ned till noll när disken har ledig tid - problemet är ofta när stora mängder småfiler skrivs så blir denna PMR-buffert full fort trots att den kan vara från 30 - 70 GB stor och disken måste börja nödstäda för att få plats för nya skrivningar och under den tiden detta pågår så svarar inte disken på förfrågningar av systemet utan disken upplevs vara responslös och när detta sker i längre tid än 8 sekunder så tolkar ZFS disken som trasig och den kickas ut - och detta vet man inte när det händer utan kan ske precis när som helst.
Dock ofta när väldigt mycket filer har skrivits eller under processer som när RAID synkas upp ('resilver' på ZFS-språk) och läses konstant och med typ var tredje eller var fjärde block skriver data (paritetsdatan) mot disken konstant hela tiden i timmar utan avbrott - vilket på SMR-diskar direkt fyller upp PMR-delen då blocken som skrivs är mycket mindre än SMR-segment och när PMR-delen är full så börja den stalla, för att disken måste nödstäda och ofta utan respons i mer än 8 sekunder.
---
SMR-diskar och SSD/NVMe-minnen av billigare sort (som QLC-minnen med SLC-cache av begränsad storlek) har väldigt liknande beteende när deras SLC-cache-minnen eller PMR-buffert har förbrukats upp av massa skrivningar på kort tid och går jämförelsvis väldigt långsam gentemot deras ordinarie hastigheter - med skillnaden att SSD/NVMe svarar inom delar av sekunder även i det läget (undantaget att när SSD gör TRIM så kan det vara borta i åtskilliga sekunder utan respons) medans SMR-disk kan vara borta längre än 8 sekunder innan respons.
Skall du driva 2.5" diskar eller dito SSD över USB3 på RPI4 så bör du ha en USB-hubb med egen strömförsörjning som orka mata de inkopplade 2.5"-diskarna - dessa kan vara rätt trassliga att hitta idag då allt är USB-C eller eller USB3 utan egen matning. håll också USB-sladden mellan USB-hubben och 2.5" USBdisken kort - inte längre än sladden som följde med disken när den köptes ny - det fins en anledning till varför denna sladd är kort när 2.5" USB-snurrdiskar skall matas över USB - provar man med längre sladd så är risken hög för strul och datakorruption av filsystemet.
Är det enbart 3.5" diskar så kan det kopplas direkt eller via en usb-hub utan försörjning då dessa diskar har egen strömförsörjning via nätadapter. Dessa tål också längre USB-sladd utan risk för datakorruption
Använd BTRF om du vill ha filsystem som är bra på att återhämta sig från olyckliga strömavbrott och annan krångel. BTRFS har checksumma på all sin data - även metadata, transaktionsbaserad och skriver aldrig över redan skriven data - inte ens på metadatanivå och gör att den kan göra rollback till sista commit:ade transaktion och verifiera att den är komplett och sedan har det som ny utgångspunkt för vidare skrivning.
Använd _inte_ NTFS om möjligt och du är rädd om datat och vill ha den kvar även efter strömavbrott och annan trassel...
NTFS på externa USB-diskar är nästan lika illa som att använda ZFS på externa USB-diskar...
Är det enbart 3.5" diskar så kan det kopplas direkt eller via en usb-hub utan försörjning då dessa diskar har egen strömförsörjning via nätadapter. Dessa tål också längre USB-sladd utan risk för datakorruption
Använd BTRF om du vill ha filsystem som är bra på att återhämta sig från olyckliga strömavbrott och annan krångel. BTRFS har checksumma på all sin data - även metadata, transaktionsbaserad och skriver aldrig över redan skriven data - inte ens på metadatanivå och gör att den kan göra rollback till sista commit:ade transaktion och verifiera att den är komplett och sedan har det som ny utgångspunkt för vidare skrivning.
Använd _inte_ NTFS om möjligt och du är rädd om datat och vill ha den kvar även efter strömavbrott och annan trassel...
NTFS på externa USB-diskar är nästan lika illa som att använda ZFS på externa USB-diskar...
Redigerat:
Diversearbetare
· Göteborg
· 10 705 inlägg
Så länge man har en (1) USB-disk per vdev i ZFS är USB-diskar inte några problem. De är ju dock inte lämpliga att köra t.ex. databaser på, men som mediabank, t.ex. filmer och backupmål fungerar de lika bra som fasta diskar. ZFS är byggt från grunden att alltid förutsätta fel och aldrig lita på disken, så en USB-disk med glappa kontakter och dåliga controllers är hyfsat enkla hinder som ZFS rundar. SMR-diskar är dock lurigt eftersom problemet är fysiskt/analogt.
Truenas kan tvinga även USB-diskar (och andra externa interface) att alltid vara vakna och har finkornig styrning av powermanagement.
Truenas kan tvinga även USB-diskar (och andra externa interface) att alltid vara vakna och har finkornig styrning av powermanagement.
Problemet är att nästan alla USB-snurrdiskar man kan köpa de senaste åren har just SMR-diskar bakom skalet - skall man runda den delen blir det att köpa stora USB-diskar kanske med dagens diskar över 14 TB för att vara säker på att det inte är SMR-diskar.
Men uppspinningstiden är ett problem - vilket en kamrat till mig fick uppleva med en RAID-uppsättning USB-diskar (innan SMR-disktiden) på en vdev där det hela tiden var en disk för mycket som blev utsparkad och det gick inte att komma åt innehållet - det blev att konsultera core-folket på ZFS innan det gick att få till och sedan dess pratar han inte om ZFS trots att han var glatt missionär för ZFS innan dess och vid fråga säger han kort - använd BTRFS på externa USB-diskar, inte ZFS - på filservrar med mycket ECC-minne och riktiga serverdiskar via SATA/SAS-buss är ZFS ett bra alternativ, men inte på USB-diskar. punkt.
- kort sagt blev han rejält bränd av situationen då det var för mycket viktig data på diskarna som var fast på dessa i tron att ZFS med redundanta diskar i vdev skulle säkra den - och så krånglade just den biten när vdev:n skulle sättas ihop...
ZFS är lite av en glaskanon - väldigt bra på sin sak men när den krånglar så är det ofta totalhaveri och inga eller mycket dåliga verktyg för att rädda data i efterhand och det bygger på att man hela tiden har en uppdaterad backup istället för att försöka reparera filsystemet.
Nu skall det sägas att uppdaterad backup gäller för all data oavsett filsystem - men vi vet hur verkligheten ser ut för väldigt många och det är först efter en väldigt svidande dataförlust som just den delen förbättras...
Men uppspinningstiden är ett problem - vilket en kamrat till mig fick uppleva med en RAID-uppsättning USB-diskar (innan SMR-disktiden) på en vdev där det hela tiden var en disk för mycket som blev utsparkad och det gick inte att komma åt innehållet - det blev att konsultera core-folket på ZFS innan det gick att få till och sedan dess pratar han inte om ZFS trots att han var glatt missionär för ZFS innan dess och vid fråga säger han kort - använd BTRFS på externa USB-diskar, inte ZFS - på filservrar med mycket ECC-minne och riktiga serverdiskar via SATA/SAS-buss är ZFS ett bra alternativ, men inte på USB-diskar. punkt.
- kort sagt blev han rejält bränd av situationen då det var för mycket viktig data på diskarna som var fast på dessa i tron att ZFS med redundanta diskar i vdev skulle säkra den - och så krånglade just den biten när vdev:n skulle sättas ihop...
ZFS är lite av en glaskanon - väldigt bra på sin sak men när den krånglar så är det ofta totalhaveri och inga eller mycket dåliga verktyg för att rädda data i efterhand och det bygger på att man hela tiden har en uppdaterad backup istället för att försöka reparera filsystemet.
Nu skall det sägas att uppdaterad backup gäller för all data oavsett filsystem - men vi vet hur verkligheten ser ut för väldigt många och det är först efter en väldigt svidande dataförlust som just den delen förbättras...
Redigerat:
Diversearbetare
· Göteborg
· 10 705 inlägg
Nu blev det väldigt OT, men för att lugna ner alla som läser om ZFS:
- - -
Det här låter som samma gamla myter med urspung från en enda sur användare från FreeNas-communityn.😎
För lite mer djupgående avlivning av myten om ZFS och ECC: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
- - -
Det här låter som samma gamla myter med urspung från en enda sur användare från FreeNas-communityn.😎
- ZFS behöver inte ECC (fråga Matt Ahrends som är en av utvecklarna) ZFS är byggt för att runda bit-problem t.ex. ”flipped bit” i RAM. ZFS är ”copy-on-write” så det skrivs ständigt och en ”mismatch” mellan data på disk och checksumman på disk upptäcks omedelbart. Gäller även ”scrub”-processer. ZFS är som sagt byggt för att aldrig lita på underliggande system och tar hand om alla sovande och aktiva problem galant.
- ZFS gillar RAM, ja. Det är inte nödvändigt för funktion, men hela cache-funktionaliteten bygger på detta. Ju mer RAM desto bättre. ZFS släpper också RAM lika lätt som det roffar åt sig.
- Om man bygger en vdev med flera olika diskar från olika interface, har man inte ens förstått den grundläggande tekniken att bygga ett väl fungerande disk-set. Det gäller för alla sorters filsystem. Oavsett om det hempuleri eller i serverhall.
För lite mer djupgående avlivning av myten om ZFS och ECC: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
Redigerat: