Union-montering i Linux med "smart" placering av filer

av **Sammelsurium** » 2012-06-02 12:20:39

Jag har köpt en HP N40L som jag ska använda som hemmaserver för mestadels centraliserad lagring, diverse småtjänster samt eventuellt senare HTPC.

Den kommer att köra någon typ av generell Linux-distribution, förmodligen Scientific Linux eller Fedora, istället för något system specialiserat för lagring som t.ex FreeNAS, eftersom jag vill ha mer flexibilitet.

Funderar lite nu hur jag ska konfigurera upp den med diskar, filsystem etc.
Det bästa hade varit att bestycka den med fyra stora diskar och köra RAID5 över dem, men det skulle innebära en hög initial kostnad för diskar, vilka dessutom förmodligen kommer att ta ett tag att fylla upp. Det känns oekonomiskt, eftersom jag i dagsläget har ett par diskar i olika storlekar över som jag vill använda.

Jag skulle kunna köra en RAID1 där jag lagrar foton och andra viktiga dokument och sedan en RAID0 på resten, där jag lägger mestadels filmer och musik, saker som jag kan ladda hem igen om det går förlorat. När behovet på lagringsutrymme ökar köper jag en ny disk och utökar RAID0:an. Men eftersom data ligger stripat kommer jag vid bortfall av en disk att förlora all data.
Bättre vore isf att köra någon typ av union-mount, så om jag tappar en disk förlorar jag bara det data som ligger på just den disken. Att läs/skrivprestandan blir lägre bryr jag mig inte om.

Finns det något filsystem till Linux (jag känner till UnionFS) där man kan union-montera ihop flera filsystem, men vid skrivning försöker filsystemet att hålla på lokaliteten så långt det går? Dvs skriver jag filer till katalogen /x/y/z ska filsystemet så långt det går försöka lägga alla filer som skrivs till katalogen z på samma underliggande filsystem.
Orsaken är att det är bättre att tappa en hel katalog, än två halva.

Någon som har gjort något liknande och kan bespara mig googlandet?

av **matgar** » 2012-06-02 12:31:56

Ett enkelt alternativ vore ju att ha 1 disk per mapp.

av **Vatgrown** » 2012-06-02 12:33:20

Har aldrig lekt med RAID och jag vet faktiskt inte vad som är möjligt och inte men vad du har är alltså två hårddiskar av varierande storlek och du vill spegla den mindre hårddisken i en partition på den större? Men varför måste du då köra striping på det restrerande utrymmet? Kan du inte bara köpa en ny hårddisk och använda den separat när utrymmet tar slut?

av **matgar** » 2012-06-02 12:43:31

Vatgrown skrev:Har aldrig lekt med RAID och jag vet faktiskt inte vad som är möjligt och inte men vad du har är alltså två hårddiskar av varierande storlek och du vill spegla den mindre hårddisken i en partition på den större? Men varför måste du då köra striping på det restrerande utrymmet? Kan du inte bara köpa en ny hårddisk och använda den separat när utrymmet tar slut?

RAID kan ju användas för olika anledningar.
Redundans.
Prestanda.
Enkelheten med att ha stora "diskar".

Pratar vi raid 0 så är man ute efter prestanda och möjligen stor "disk"
Vill man bara ha en stor "disk" så kan man köra JBOD.

Angående OPs orginal fråga så har jag för mig att jag läst om möjligheten att flytta runt data till/från specifika diskar i jbod volymer men om det funkar on the fly vid skrivning till disk har jag ingen aning.

av **Vatgrown** » 2012-06-02 12:56:24

Jo. Men det finns ju ingenting att stripea mot om han då inte köper en till hårddisk. Jag visualiserade det som:

Kod: Markera allt: 11111111111111111100000000 hda 111111111111111111 hdb

Och med en extra håddisk:

Kod: Markera allt: 00000000000000000000000000 hdc 11111111111111111100000000 hda 111111111111111111 hdb

Efter lite googlande så verkar det som om man inte heller kan lägga till en disk till en existerande RAID0-array.

av **Miche** » 2012-06-02 12:57:00

Jag funderar på en lösning liknande Dropbox/Google Drive, dvs när en fil skrivs/uppdateras i en bevakad mapp så kopieras den även till en backupdisk.

av **Sammelsurium** » 2012-06-02 13:30:23

Vatgrown skrev:Har aldrig lekt med RAID och jag vet faktiskt inte vad som är möjligt och inte men vad du har är alltså två hårddiskar av varierande storlek och du vill spegla den mindre hårddisken i en partition på den större?

Ja, ungefär, men det kommer att bli fler diskar med tiden. Den här delen är inget problem, bara att skapa två partitioner på olika diskar och köra en RAID1 på dem.

Men varför måste du då köra striping på det restrerande utrymmet? Kan du inte bara köpa en ny hårddisk och använda den separat när utrymmet tar slut?

Grejen är att jag utöver det säkra utrymmet på RAID1:an vill slå ihop allt övrigt utrymme till ett enda filsystem. Att manuellt lägga saker på olika diskar är bökigt. Man får flera olika hierarkier att söka igenom för att hitta det man vill ha.
Sen ska jag dela ut filsystemet till övriga datorer i huset via NFS/CIFS och då vill jag kunna göra det med en enda montering.

av **Sammelsurium** » 2012-06-02 13:54:17

Vatgrown skrev:Efter lite googlande så verkar det som om man inte heller kan lägga till en disk till en existerande RAID0-array.

Nej, det verkar så. Däremot fungerar det bra under LVM, som också kan stripa på olika sätt.

Av de olika union-lösningarna jag har hittat verkar ingen ingå i en standard-Linux-kärna. Dessutom verkar syftet med dem vara att kombinera skrivskyddade och skrivbara filsystem, t.ex för att göra filsystemet på en live cd skrivbart genom att skrivningar går till en USB-sticka.

Ska kolla lite på distribuerade filsystem, trots att det är overkill för vad jag vill ha. Dessutom verkar det inte som om något av dem ingår i en vanlig kärna och vara rätt meckiga att sätta upp.

av **weasley** » 2012-06-02 13:57:58

Lättaste när man har massa olika diskar där man inte är rädd att förlora en viss data är att göra såhär:

Skapa en mount point. Exvis

Kod: Markera allt: $mkdir /mydisks

Skapa undermappar, en för varje kategori.

Kod: Markera allt: mydisks$mkdir film [..]

Mounta rätt disk till rätt mapp. Du kan tex göra en RAID5 för viktiga saker och mounta under /mydisks/ReallyImportantStuff medan din skruttdisk på 80GB mountas under /mydisks/SkruttSaker.

Dela ut /mydisks, exvis via Samba. Det här går att göra under vilken Linuxdist som helst. Min egen serverfavorit är Slackware. De har massa fina inbyggda tools för sånthär.

Var det något sånt du ville göra?

av **Sammelsurium** » 2012-06-02 14:14:41

weasley skrev:Var det något sånt du ville göra?

Precis, men jag vill slippa att knyta en disk till en kategori.

Säg att t.ex filsystemet /mydisks/Movies/ blir fullt. Jag köper en ny disk som hamnar under /mydisks/Movies2 där jag lägger nya filmer. När jag sedan ska kolla på en film måste jag leta i både /mydisks/Movies och /mydisks/Movies2 för att hitta den.
Dessutom kanske det fanns en del plats på /mydisks/Music som inte kommer till användning. Då får jag skapa en katalog "Movies" där också, med underliggande hierarkier, för att utnyttja den.

Det är samma sak som när man lägger /home på en separat partition. När utrymmet på /home är slut måste man börja flytta saker till /usr som inte här hemma där. Till sist ligger filerna spridda över olika diskar och partitioner.

Jag hittade http://romanrm.ru/en/mhddfs (funionfs verkar fungera ungefär likadant).

Fungerar såhär:

Kod: Markera allt: $ mkdir -p disks/{1,2,3} test/mnt $ mhddfs disks/1/,disks/2/,disks/3/ mnt/ $ touch mnt/a $ find disks -name a disks/1/a $ touch disks/2/b $ find mnt -name b mnt/b

Det verkar vara ungefär vad jag vill ha, men saknar inställningar för att styra var saker ska hamna i de underliggande filsystemen. Dessutom känns det lite "hackigt". Jag skulle vilja ha något robust och vältestat.

av **Miche** » 2012-06-02 14:33:49

Jag skulle akta mig väldigt noga för saker på ryska sajter!

av **Sammelsurium** » 2012-06-02 14:37:54

Miche skrev:Jag skulle akta mig väldigt noga för saker på ryska sajter!

Fast själva verktyget (mhddfs) fanns tillgängligt i Fedoras repository och installerades med yum. Jag hoppas att RedHat-folket har koll på vad de stoppar in i sina distributioner.

Annars hade jag nog hoppat över det.

av **Vatgrown** » 2012-06-02 15:21:45

Nu har jag ingen data att backa upp det här med, men .ru är nog egentligen inte värre än någon annan domän bara för att det är mycket organiserad cyberbrottslighet i ryssland.

av **weasley** » 2012-06-02 16:50:54

Sammelsurium skrev:Säg att t.ex filsystemet /mydisks/Movies/ blir fullt. Jag köper en ny disk som hamnar under /mydisks/Movies2 där jag lägger nya filmer. När jag sedan ska kolla på en film måste jag leta i både /mydisks/Movies och /mydisks/Movies2 för att hitta den.

Kör UnionFS på de diskar du tror du kommer behöva expandera senare. Du behöver inte köra det på alla, bara de du väljer ut. Då lägger du bara till den nya disken under /mydisks/Movies som en union med den existerande. Praktiskt och elegant.

av **Sammelsurium** » 2012-06-02 18:49:20

Ja, det var så jag menade i ursprungsinlägget (om jag inte missuppfattar dig).

Grejen är att vid skrivning till själva unionen, vill jag att filer som har hög "lokalitet" (dvs ligger nära i hierarkin) om möjligt ska hamna på samma disk. Dessutom vore det trevligt med någon typ av wear leveling så att inte samma disk får jobba hela tiden.

Eftersom den funktionaliteten inte verkar finnas i de filsystemen jag har tittat på funderar jag på att sätta upp katalogstrukturen som följande:

Kod: Markera allt: /export (exporteras via NFS/CIFS) +-vols +-vol1 (disk 1) +Movies +-vol2 (disk 2) +Movies +-Movies (union av /export/vols/vol1 och /extport/vols/vol2)

När jag ska skriva filer så lägger jag dem manuellt i antingen /vols/vol1 eller /vols/vol2 för att se till att material som hör ihop hamnar på samma disk.

Sen kan jag läsa från materialet från unionen /Movies.

Det trista är att om jag t.ex kör ett par nedladdningar mot vol1 och diskutrymmet tar slut måste jag pausa nedladdningarna (om det är möjligt), frigöra utrymme på vol1 och sedan återuppta nedladdningarna. Trots att det finns plats på vol2.

Vet du förresten vad som krävs för flaggor i /etc/exports för att de filsystem som är monterade i en katalog X ska "följa med" då X exporteras via NFS?

Låt oss säga att katalogen /export exporteras på min maskin via NFS. Jag gör en montering i /export och monterar /export under /mnt via NFS:

Kod: Markera allt: export$ mkdir tmp export$ mount /tmp tmp -o bind export$ mount localhost:/export /mnt

Nu är /mnt/tmp är tom, trots att /exports/tmp innehåller filer.

av **Sammelsurium** » 2012-06-02 19:03:44

Hittade det.

/etc/exports:
/export/tmp 127.0.0.1(nohide,fsid=0)
/export/ 127.0.0.1(crossmnt,fsid=1)

av **weasley** » 2012-06-02 19:46:12

Sammelsurium skrev:Eftersom den funktionaliteten inte verkar finnas i de filsystemen jag har tittat på funderar jag på att sätta upp katalogstrukturen som följande:

Ser bra ut.

Sammelsurium skrev:Det trista är att om jag t.ex kör ett par nedladdningar mot vol1 och diskutrymmet tar slut måste jag pausa nedladdningarna (om det är möjligt), frigöra utrymme på vol1 och sedan återuppta nedladdningarna. Trots att det finns plats på vol2.

Det här problemet känner inte jag till att man kan gå runt. Antingen har du bara en /mydisks/MinaFiler där du har vol1+vol2 som en union och filerna hamnar någonstans där, eller så måste du trixa på det vis du skriver om. Sorry.

av **weasley** » 2012-06-02 19:52:10

Justja, om du verkligen vill se till att saker hamnar på rätt disk, som du beskriver, då är det enklast att strunta i unionen eftersom du ändå måste ta bort utrymme på vol1 i det fall du beskriver. Då kan du lika gärna göra en vanlig mount point, den ena heter vol1 och den andra vol2.

Grejen med unionfs är just att slippa tänka på hierarkierna och vad som ligger var eftersom filsystemet ser det som en enda disk och blir den ena full så skrivs det till den andra automatiskt.

Om man vill ha seriös ordning (vilket jag gillar) så räcker vanliga mount points. Själv använder jag enbart mount points för att då kan jag ha min nazistordning och samtidig stenkoll på ev platsbrist.

av **Sammelsurium** » 2012-06-02 21:20:51

Då är frågan om det finns något annat filsystem, där förlust av x% av diskytan enbart innebär förlust av x% (på ett ungefär) av filinnehållet. Tappar man en disk i en RAID0 förlorar man ju precis allt.

av **Erathe** » 2012-06-03 1:03:14

Kombinera mhddfs med snapraid. Använd vilket filsystem du vill under.

av **weasley** » 2012-06-03 2:05:05

Men mhddfs det ger ju samma resultat som unionfs - du vet fortf inte VAR filerna befinner sej. Som jag förstått det vill Sammelsurium ha lite koll på det.

Så det spelar ingen roll vilken sorts RAID man använder. Snapraid har jag dock inte använt någonsin så jag får väl googla lite på det.

*********

EDIT: Hittade länk om snapRAID: http://snapraid.sourceforge.net/

av **weasley** » 2012-06-03 2:14:53

Sammelsurium skrev:Då är frågan om det finns något annat filsystem, där förlust av x% av diskytan enbart innebär förlust av x% (på ett ungefär) av filinnehållet. Tappar man en disk i en RAID0 förlorar man ju precis allt.

En RAID-5 kräver tre diskar men du kan återskapa all data om bara en av diskarna gått sönder, eftersom de fördelar checksummorna på ett strategiskt sätt. Så du kan ju göra en RAID5 och mounta under /mydisks/myraid5disk och där lägga all viktig data.

En lite rolig grej är att du kan RAID5-a tre diskar, RAID0-a två, slå ihop dem med unionfs (eller det som Erathe nämnde) och sen mounta rubbet som en enda enhet. Vad du skulle tjäna på det är dock inte riktigt lika uppenbart. Oavsett vilket union-system du använder har du aldrig fetkoll på vad som ligger var. För att få det måste du gå in och styra manuellt, flytta mappar från en disk till en annan, eftersom unionfilsystemen lägger mappen där den finner det lämpligt. Men om du är beredd att göra det så kan du absolut köra unionsystem.

Det är bara jag som tycker att sånt är onödigt när man vill ha stenkoll på vad som ligger var och när en enskild disk blir full etc. Min egen lagring är konfad som 3xRAID5 där varje enhet är mountad i en separat katalog. På det viset vet jag att saker hamnar på rätt ställen.

av **Sammelsurium** » 2012-06-03 9:09:15

Erathe skrev:Kombinera mhddfs med snapraid. Använd vilket filsystem du vill under.

Snapraid verkar intressant, efter en väldigt kort genomläsning. Det skulle lösa problemet att jag slipper tappa all data om en disk rasar. Frågan är om det går att köra i RAID0-läge, dvs helt utan redundans.

SnapRAID skrev:-You can start using SnapRAID with already filled disks.
-The disks of the array can have different sizes.
-You can add disks at any time.
-If you accidentally delete some files in a disk, you can recover them.
-If more than two disks fail, you lose the data only on the failed disks. All the data in the other disks is safe.
-It doesn't lock-in your data. You can stop using SnapRAID at any time without the need to reformat or move data.
-All your data is hashed to ensure data integrity and to avoid silent corruption.

Weasley skrev:Oavsett vilket union-system du använder har du aldrig fetkoll på vad som ligger var. För att få det måste du gå in och styra manuellt, flytta mappar från en disk till en annan, eftersom unionfilsystemen lägger mappen där den finner det lämpligt.

Jag kollade tidigare på en distribuerad ftp där man just satte upp regler för master-noden i ftp-klustret, till vilken slavnod olika kommandon skulle skickas, baserat på sökvägen i kommandot.
Eftersom det skulle vara en perfekt feature för ett union-filsystem, så hoppades jag at det måste något liknande till Linux. Men icke, verkar det som.

Moderator: Justerade SnapRAID-citatet så det blev ett citat, kan passa på att påpeka att en citatquote ska se ut som nedan (där namnet är omgivet av "):

Kod: Markera allt: [quote="namn på citatet"]

av **Erathe** » 2012-06-03 11:05:08

Snapraid är bara till för backup ifall en disk skulle konka. Den skapar paritetsdata på samma sätt som raid5 men det är allt den gör. Det är inget filsystem utan använder dina existerande filer i ditt vanliga filsystem och det är inte heller union mount.

Tanken med snapraid i ditt fall var att det inte borde spela någon roll vilken disk filer läggs på om du kan försäkra dig om att du inte tappar filer när diskar dör. Mhddfs kod är mycket enkel så om du har lite basic C skill kan du lägga till den funktionalitet du vill utan större problem.