Bygga egen billig strömsnål NAS.

Jag har kört 6st 3.5"-diskar i det chassit, och temperaturerna kryper gärna över 40 på vissa diskar även med fläktarna i full hastighet. Så tyst kan nog vara svårt om du fyller chassit.

Angående OS så kör jag själv en vanlig ubuntu-desktop eftersom burken även dubblar som HTPC, för storagen så kör jag BTRFS i RAID1. Det funkar väldigt bra, och övriga tjänster som Sonarr och Deluge rullar i LXC-containers.

Jag körde med de fläktar som kom med chassit. Det ljud som hördes var både fläktar och vibrationer från diskarna trots upphängningen i chassit och extra tjocka gummifötter.

Det går att förklara på olika nivåer baserat på din kunskap. Men väldigt basic så är det en virtuell maskin som delar kärna med värden. Detta gör att du får mindre overhead, men du kan inte köra windows som gäst t.ex En jämförelse är jails i BSD. Docker är ett exempel som använder sig av containers.

Lite mer avancerat så sätts det upp ett nytt namespace i kerneln och alla processer som körs är isolerade från värden.

Hur menar du att risken för datakorruption ökar för att du kör RAID?

Man låter Nas programvaran hantera dataskyddet motsvarande raid funktionalitet. Därav SKA man inte använda raid från moderkortet utan vanliga "dumma" sata anslutningar är det man vill ha.

Med Xpenology så kan man bara köra read-cache om man har en ssd som cache. vill man ha write så krävs två. Just så att en rasad cache disk inte leder till dataförlust.

BTRFS 'raid1' är inte någon vanlig sektorspeglande RAID som de flesta HW-Raid och mdm-RAID1

Filosofin är ganska enkel - varje fil som skrivs - skrivs alltid med två kopior på två fysiska diskar med varsina filsystem, journaler etc. vilket också innebär att filerna hamnar på olika ställen på resp. disk. BTRFS har dessutom checksumma på sina sektorer så de kan validera att sektorn är korrekt och med varsina journaler också bestämma vilken fil i filparet skrevs sist vilket hanterar write-hole situationer (write-hole - inkonsistens som kan bli i sektorspeglande RAID1 om strömmen bryts mitt under diskskrivning och det drevs olika mycket mellan diskarna i diskparet - ingen sektor uppvisar läsfel vid senare omstart men olika diskar har olika information på samma sektorposition och RAID-systemet kan inte själv avgöra vilken som är den korrekta sektorn i och med att de har ingen övergripande system som håller reda på skrivordningen mellan diskarna.) .

i BTRFS RAID1-läge kan man också plocka på udda diskstorlekar och tex. köra med 3 diskar eller 2 8TB och 1 4TB diskar och av detta plocka ihop 10 TB tillgänglig diskyta. Dock att tänka på är att BTRFS 'RAID-1' klarar bara 1-diskbortfall även om setupen består av 4 diskar av olika storlek.

Detta stämmer väldigt ofta i praktiken, men inte helt i teorin.
Låt säga att du har börjat med två diskar och fyllt upp dom helt, för att sedan lagt till 2 till. Du kan då tappa en ur det gamla "paret" och en ur det nya "paret".
Det går även att montera filsystemet degraded (det är ett krav om du saknar en disk) och plocka ur den data som finns kvar. I värsta fall så finns det även program som går igenom disken block för block och läser allt som ser ut som en fil från BTRFS.

Raid 5 o 6 i BTRFS har haft experiment/utvecklingsstatus länge och det beror på att den delen är svårt underfinansierad, och därmed i princip ingen utveckling alls - medans dess RAID1 anses nog ganska så stabil idag eftersom det var det Novell satsade pengar på för sina egna behov - och när de var tillfyllest så sinade kassan.

idag så rekommenderas knappt RAID5 och 6 alls längre utan mer på RAID1 och RAID10 lösningar mm. så behovet kanske inte känns så skriande för Raid5 o 6 och därav ingen fart på utvecklingen av det.

Man kan alltid väga förr och nackdelar - BTRFS behöver inte alls lika stor footprint rent resursmässigt som ZFS. Dock håller jag nog med att ZFS förmodligen är den säkraste filsystemet just nu om man kan matcha med rätt HW för det.

Btrfs är förlåtande och klarar taskiga situationer som glappande USB-sladdar till externa diskar och mycket annat i den vägen som jag har gjort både avsiktligt och av misstag och vet hade skrotat NTFS till oräddningsbar nivå.

Mycket filer och arkiv ligger numera på BTRFS och hittills har det inte gjort mig besviken med några oavsiktliga filförluster trots nu snart 3 års användande - medans jag har tappat hela diskar med NTFS tidigare i historien - och jag vet två st 4-k kluster man kan skriva över på NTFS-filsystem med skräptal om man vill ha det förbaskat jobbigt att göra recovery och filräddning [1] - dom flesta disk och filräddningsprogram klarar inte just den situationen och man hamnar på läge data-scraping vilket innebär väldigt många filer med $nummer under ett enda direktory och att man inte vet om filkroppen är komplett eller korrupt eller har inlänkade bitar av raderade eller andra filer i sig.

[1] Nej jag listade inte ut det själv - det gjorde en USB-hårddisk-kabinett åt mig - närmare bestämt en WD-Book... - och vi pratar om två blocken/klustren som är de första som läses in när NTFS mountas och de två sista som skrivs när disken avmountas - och på XP-tiden så kom också en avstängningsorder (lysdioderna slocknade på USB-stickan, motorn i snurrdisken stängdes av etc.) i samband med att man avmonterad/ejektade en USB-disk (det gör det inte idag av någon anledning - kanske av samma anledning jag råkade ut för - en skrotad NTFS i vissa USB-enheter) med 'säker borttagande av hårdvara' vilket resulterade att dom här två viktiga sektorerna fylldes med slumptal och skrevs på disken på två helt olika platser på diskytan innan disken stängdes av - det är inte bra, det är inte bra alls för ett NTFS filsystem...