Pen skrev:xxargs skrev:
Som filsystem för lagringsdisk så skulle jag överväga BTRFS - förutom att både data och metadata är checksummat så är den enormt flexibelt i att kunna öka och minska filystem på diskar, skarva i en disk till om platsen tryter, lätt att ta bort igen om det blir gott om plats igen välja olika raid-moder och kan konvererteras online medans systemet används.
BTRFS är säkert väldigt tillförlitligt som du säger, men jag tog in en annan aspekt som vägde tyngre (jag har inte heller något expanderbart system i åtanke - det är mera en boxtanke). Om något går permanent sönder så vill jag snabbt få till en "limpmode" (baserat på erfarenhet). Det jag tänker mig då är att om t.ex. RPi själv går sönder så ska jag kunna plugga in den externa hårddisken någon annanstans. Som jag ser det har jag tre val:
1. Jag har en ersättnings RPi liggandes (ingen limpmode egentligen)
2. Jag pluggar in disken i den laptop som för tillfället behöver åtkomst
3. Jag pluggar in disken i någon annan burk som kan hantera den - i mitt fall min Linksys router
I fall 1 går det att välja godtyckligt filsystem, i fall 2 är NTFS att föredra, i fall 3 är det ext3 eller NTFS som gäller. Det finns visserligen drivrutiner för ext3 till Windows men de verkar inte vara att lita på (och de kommer inte att vara installerade på alla laptops i familjen). Omvändningen (NTFS på Linux) verkar vara betydligt säkrare men någonting bär mig emot. Så jag lutar mot alternativ 3 och ext3 men är osäker.
Följdfrågor:
Vad är nackdelen med NTFS på Linux? Finns mycket om detta på nätet men det besudlas av religiösa inställningar så jag får inget grepp om det. Både NTFS och ext3 är journalfilsystem.
Klarar RPi prestandamässigt BTRFS? Jag har väl inte helt uteslutit alternativ 1. Om jag bygger backup noden på samma sätt så går det ju att "låna" delar av den i nödfall (istället för att ha reservdelar i skrivbordslådan).
Jag som är analog-guy i grunden får rysning är det är mer än enstaka mV i HF-rippel - 50 till 250 mV anser jag inte är OK, likaså den usla lastregleringen.
Det är sådant som kan döda SD-brickor
---
När det gäller filsystem så kan du stoppa nästan vad fasen som helst i en linuxhink med tex ubuntu, udev där kommer att identifiera och montera en BTRFS lika säkert som någon av ext-filsystemen liksom NTFS då det är en del av kärnan numera.
skall du göra diskrecovery så gör det inte i en windows-burk - utan du gör det i en Linux-burk!! (även så startad på USB-sticka eller en live-CD)
NTFS på RPi - nej skulle jag vilja säga - med tanke på hur mycket CPU som dricks när man skall köra mot en NTFS-image även på vanlig linuxdator så skulle jag nog tänka mig något annat.
Sedan är NTFS ömtålig på ett par 4K-kluster [första 4KB av $MFT och hela $MFT_mirr överskriven med slump] och som jag har synnerligen dålig erfarenhet av i samband med externa hårddiskar av WD-book modell där man av dess USB-chip i vissa situationer får båda sönderskrivna samtidigt i ett enda moment i samband med stängning av filsystemet och man får en disk vars innehåll är i stort sett ej räddningsbar ens med kommersiella diskräddningsprogram utan det är bara datacraping kvar utan att veta om filkroppen är komplett eller sönderhackad med andra skrivningar för att filerna var fragmenterade och räddningsprogrammet försökte att läsa sekvensiellt...
Vill du inte experimentera - kör ext4, är du mer villiga att prova - prova BTRFS - när du väl provat att göra snapshot innan tex. en uppdatering av en backup från någon annan datorn som gör backup över nätverket - så vill du inte ha något annat i fortsättningen...
dock en sak som drar ned användandet av RPI3 som NAS är den begränsade hastigheten på dess USB2, som den också delar med nätverkstrafiken och det kommer inte att gå fort att fylla TB-stora diskar via nätverket - i så fall förfyll diskarna med annan Linux-hink om det handlar om mediabibliotek/foton och sedan koppla in RPI för till största delen bara läsning - räkna inte med mycket över 10 MB/s i överföringshastighet från disk till nätverk...
om RPI:s SoIC kunde köra med 1 GBIT internt så hade mycket varit förlåtet, men nu är den smala kanalen som USB2 ger en rejäl handikap för RPI:s totala prestanda om man skall ha den för filskyfflande