[JBOD:aufs] Alle schijven hot-pluggable onder één mountpoint

[Sando]

-update-

Mijn zoektocht naar LVM waarbij diskuitval niet het hele volume neerhaalt stuitte als eerste op aufs.

Het kan aufs niet schelen als een schijf uitvalt. Dan ben je gewoon de gegevens op deze schijf kwijt, maar de content van de andere schijven staat nog in je mountpoint. Ook kan je dynamisch schijven verwijderen/toevoegen van/aan je mountpoint. Dat maakt het zoveel handiger boven RAID of SPAN achtige oplossingen wanneer redundancy toch niet gewenst is.

Het relevante deel van dit topic begint hier: aufs ftw!

Als je de discussie omtrend de zoektocht wilt lezen, dan kan je hieronder beginnen:

Originele post:

---

Originele titel: LVM waarbij diskuitval niet het hele volume neerhaalt?

Door de jaren heen komt er afentoe een harddiskje bij in één van mijn computers, en ik dacht het mooi voor elkaar te hebben door de oudste (en dus meest onbetrouwbare) schijven in mijn Media Center dmv LVM op een hoop te gooien en zo één dik volume te maken waarop ik ongegeneerd media kan plempen.

Als een schijf kapot gaat, dan ben ik maar alles kwijt wat er op staat, als de rest maar vrolijk door gaat.

Echter wat hoor ik nu? Ookal pas je geen striping toe en plaats je gewoon meerdere disks achter elkaar in een groot volume, dan nog is je volume naar de glowten als één schijf uitvalt. Maar dat was het plan niet!

Voor mijn gevoel was het heel logisch dat de rest er gewoon nog was, maar dit zal technisch wel niet feasable zijn geweest oid. Ook PhotoRec is niet cool, want in tegenstelling tot NTFS recovery is er bij EXT file recovery niets van de bestandsnaam of directorystructuur over.

Dus vroeg ik mij af.. weet iemand truukjes waarbij ik alsnog bovenstaand idee kan uitvoeren?

[ Voor 32% gewijzigd door Sando op 29-09-2011 16:37 ]

[moto-moi]

Je haalt volgens mij RAID en LVM doorelkaar. Dat zijn geen synoniemen voor elkaar

[Sando]

Nee dat weet ik, ik heb het hier over LVM. Het lijkt natuurlijk wel op elkaar.

Wikipedia over LVM:

In particular, a volume manager can concatenate, stripe together or otherwise combine partitions into larger virtual ones that administrators can re-size or move, potentially without interrupting system use.

Ik heb nu van 3 schijven een logical volume gemaakt met de naam MediaLV. Ik dacht dat als er één uitvalt dat ik dan gewoon de rest van de data nog in die map directory had staan, maar nu hoorde ik van andere Ubuntu'ers dat bij uitval van één schijf de rest ook onleesbaar is en je zult moeten PhotoReccen om iets terug te krijgen.

Maar als je met het door elkaar halen bedoelt dat het WEL klopt wat ik dacht, schroom niet om me het goede nieuws te vertellen, want dan voeg ik er nog een schijf aan toe. Zo niet dan kan ik deze beter eerst als backup gebruiken om de LVM te debanden en een andere truuk te gaan toepassen.

[ Voor 19% gewijzigd door Sando op 30-10-2010 14:07 ]

[blaataaps]

moto-moi schreef op zaterdag 30 oktober 2010 @ 14:01:
Je haalt volgens mij RAID en LVM doorelkaar. Dat zijn geen synoniemen voor elkaar

Volgens mij haalt hij ze niet per se doorelkaar, maar wil hij een hybride systeem wat nu nog niet bestaat.
Zijn redenering was, LVM doet, in tegenstelling tot RAID 0, geen striping, maar combineert wel de schijfruimte van alle schijven tot 1 groot volume (JBOD). Doordat er geen striping is, ben je als schijf 1 uitvalt, de helft van wat er op je volume stond kwijt, maar de andere helft zou er dan nog moeten zijn.

Theoretisch zou dit moeten kunnen, met een filesystem wat hiervoor gebouwd is, maar voor zover ik weet bestaan deze niet. Op dit moment heeft het filesystem geen weet van wat er op welke fysieke schijf staat, deze ziet alleen maar het hele LV zoals aangeboden door LVM. Anderzijds heeft LVM geen weet van welke data in het LV wat voor betekenis heeft, en kan LVM dus niet anders dan het als geheel beheren.

[blaataaps]

Sando schreef op zaterdag 30 oktober 2010 @ 14:04:


Wikipedia over LVM:

[...]


Ik heb nu van 3 schijven een logical volume gemaakt met de naam MediaLV. Ik dacht dat als er één uitvalt dat ik dan gewoon de rest van de data nog in die map directory had staan, maar nu hoorde ik van andere Ubuntu'ers dat bij uitval van één schijf de rest ook onleesbaar is en je zult moeten PhotoReccen om iets terug te krijgen.

Dit lijkt me op dit moment correct. Wat wel kan, als je er net op tijd bij bent en de schijf nog niet helemaal kapot is, is zonder dataverlies een schijf uit de configuratie halen (ik weet niet meer precies hoe het heet, maar als je genoeg vrije ruimte hebt in een volumegroup kun je aangeven dat alle data van een bepaalde PV weggemigreerd moet worden).

[Sando]

Jammer. Het heeft dus weinig nut om uit veiligheidsoverweging geen snelheidsbevorderende striping toe te passen, want het gevaar is even groot dat je toch alles kwijt bent.

Iemand vertelde me dat het mss via ZFS kan maar dat ziet er nog veel ingewikkelder uit dan simpel LVM.

-edit- ik zag je laatste reactie nog niet:

Ah dan zal ik dat doen als een schijf in mijn huidige LVM over een SMART treshholt heen komt. Maar ik zoek nog een betere oplossing.

[ Voor 26% gewijzigd door Sando op 30-10-2010 14:19 ]

[blaataaps]

ZFS doet inderdaad volume management en filesystem allebei zelf, als er een systeem is wat dit zou moeten kunnen, zou ik ook op ZFS gokken. Dit zou ik onder linux echter niet proberen.

[Sando]

Je noemde eerder JBOD en dat doet me meteen aan Google denken (artikeltje eens op Tweakers). Er zijn toch wel meer bedrijven die graag een groot volume hebben met zoveel schijven dat het echt niet kan dat alles kapot gaat als er één uitvalt?

Of is dat gewoon een ingewikkeld proces waar iemand met een mediacentertje beter niet aan kan beginnen?

[Nielson]

Onder linux is btrfs misschien een alternatief?

[Sando]

Nielson schreef op zaterdag 30 oktober 2010 @ 14:23:
Onder linux is btrfs misschien een alternatief?

Bedankt voor de tip. Maar dat is voor het eerst experimenteel geimplementeerd in Ubuntu 10.10. Vind ik eng.
(en ik draai alleen LTS (10.04))

[GH45T]

Of in Windows je schijven mounten in een map als aanvulling op of in plaats van een schijfletter?

Dat doe ik hier zelf ook. Heb een RAID5 volume in mijn server, de losse harddisks heb ik in folders gemount staan zodat ik toch alles via één share kan benaderen. Het vergt wat sorteerwerk en dergelijke, maar eenmaal ingericht werkt het zo goed als transparant

[moto-moi]

blaataaps schreef op zaterdag 30 oktober 2010 @ 14:09:
Volgens mij haalt hij ze niet per se doorelkaar, maar wil hij een hybride systeem wat nu nog niet bestaat.
Zijn redenering was, LVM doet, in tegenstelling tot RAID 0, geen striping, maar combineert wel de schijfruimte van alle schijven tot 1 groot volume (JBOD). Doordat er geen striping is, ben je als schijf 1 uitvalt, de helft van wat er op je volume stond kwijt, maar de andere helft zou er dan nog moeten zijn.

Dat hybride systeem bestaat wel hoor, dat heet gewoon hardware raid Waardoor de failover niet op LVM niveau gebeurt, maar gewoon op hardwarematig niveau.

[blaataaps]

moto-moi schreef op zaterdag 30 oktober 2010 @ 14:29:
[...]

Dat hybride systeem bestaat wel hoor, dat heet gewoon hardware raid Waardoor de failover niet op LVM niveau gebeurt, maar gewoon op hardwarematig niveau.

Dat hardware-raid bestaat wist ik gelukkig al, maar zijn er hardware-systemen die aangeven "file x,y,z zijn weg, want schijf 1 is dood, maar geen probleem hoor, ik heb file a,b,c nog wel want die stonden op schijf 2" in een JBOD-configuratie?
De meeste hw-raidcontrollers die ik ken, hebben bijzonder weinig kennis van filesystems en hun layout, en zijn idee was juist dat er geen failover plaatsvindt, maar dat dataverlies van de gegevens op de falende schijf prima acceptabel is in zijn geval.

[blaataaps]

Sando schreef op zaterdag 30 oktober 2010 @ 14:22:
Je noemde eerder JBOD en dat doet me meteen aan Google denken (artikeltje eens op Tweakers). Er zijn toch wel meer bedrijven die graag een groot volume hebben met zoveel schijven dat het echt niet kan dat alles kapot gaat als er één uitvalt?

Die opties zijn er ook, maar die beschermen gelijk alle data Als je een groot volume hebt, willen de meeste mensen of het hele volume beschermen, of het hele volume niet. Een beetje van allebei is niet echt gangbaar

Of is dat gewoon een ingewikkeld proces waar iemand met een mediacentertje beter niet aan kan beginnen?

Dat moet je voor jezelf besluiten denk ik

[Sando]

Ah jammer. Zo grootschalig met gegevensbescherming is nu ook weer niet nodig.
Dat wordt dan gewoon ouderwets 4 schijven in 4 dirs mounten, en handmatig zorgen dat de locatie van incoming niet te vol raakt.

[Sando]

Wikipedia: Non-RAID drive architectures

The Mac OS X 10.4 implementation – called a "Concatenated Disk Set" – does not leave the user with any usable data on the remaining drives if one drive fails in a concatenated disk set, although the disks otherwise operate as described above.

Concatenation is one of the uses of the Logical Volume Manager in Linux, which can be used to create virtual drives spanning multiple physical drives and/or partitions.

Dan vraag je je toch af waarom dat expliciet wel bij de OSX implementatie wordt vermeld, en niet bij de LVM variant....

[deadinspace]

Volgensmij is wat jij wil wel te bereiken, alleen zul je in het geval van diskfalen moeite moeten doen om LVM te recoveren, zie bijvoorbeeld deze pagina.

In plaats van een daadwerkelijke nieuwe disk zou je dan kunnen spelen met bijvoorbeeld een sparse loopback file. Dat kost minimale ruimte, maar je kan dan wel bijvoorbeeld fscken.

Maar hou er rekening mee dat het niet zo simpel is als "Je verliest deze en deze files, en verder is het allemaal happy". Je sloopt gewoon een grote hap uit je filesystem, en dat heeft zo zijn gevolgen. Denk bijvoorbeeld aan fragmentatie; als van een film ook maar één stukje op de uitgevallen disk stond, dan krijg je daar problemen mee. Of wat als de inode voor /films op de uitgevallen disk stond? Dan kun je alle files onder /films niet meer benaderen, zelfs niet als ze op een andere disk staan. Je kunt die dan wel terughalen met fsck, maar zo eenvoudig als jij wil wordt het nooit.

Als je die disks niet vertrouwt zou ik daar allemaal niet aan beginnen, maar liever gewoon een filesystem per disk doen. Dan is het heel duidelijk afgebakend wat je verliest als er een disk uit klapt. Je zou dan met symlinks alsnog een voor jou handige structuur kunnen handhaven, en je zou voor het toevoegen van files zelfs een scriptje kunnen maken dat automatisch een disk zoekt waar nog ruimte is, en de nodige symlinks aanmaakt.

[CAPSLOCK2000]

Wat jij wil heet unionfs. Er zijn verschillende versies van, oa een kernel implementatie en een fuse implementatie.
Je op de schijven gewoon losse filesystems aan en voegt die met unionfs samen. Je ziet dan 1 directory met de inhoud van alle schijven.

[itsme]

GH45T schreef op zaterdag 30 oktober 2010 @ 14:27:
Of in Windows je schijven mounten in een map als aanvulling op of in plaats van een schijfletter?

Dat doe ik hier zelf ook. Heb een RAID5 volume in mijn server, de losse harddisks heb ik in folders gemount staan zodat ik toch alles via één share kan benaderen. Het vergt wat sorteerwerk en dergelijke, maar eenmaal ingericht werkt het zo goed als transparant

Dit is denk ik het meest eenvoudige systeem, doet precies wat je wil toch?

[jan99999]

Unraid is wat je nodig hebt(dacht ik, misschien windows home server), hier kun je de opslag die jij wilt maken zo verdelen:
Films alleen op schijf 1.
Zelf gemaakte films op schijf 1 en 2 en 3
etc, de grootte kun je ook aanpassen.
You tube staan films en op http://www.category5.tv/show_notes/


Maar wat jij wilt is eigenlijk raid 5 of 6(6 is beter) en daar boven op LVM.
Dit kun je dan ook repareren.

[CyBeR]

Het probleem is dat LVM (en het bovengenoemde concatenation in osx) werkt op block-niveau. Dus jij maakt van een zooitje disks een grote disk, en daarna zet je er een filesystem op. Op het moment dat dan een van die disks pleite raakt ben je een enorm stuk van je filesystem kwijt en weet die niet meer wtf er dan aan de hand is. ZFS doet overigens hetzelfde maar dan zonder de scheiding LVM/FS. Die kan dit ook niet.

Wat jij wilt is per disk een filesystem, en die dan weergeven alsof het één groot ding is.

Ik weet eigenlijk niet van FS'en die dit wel kunnen. Mischien is er iets dat FUSE voor je kan betekenen. Het is ook wel lastig: wat als twee van die drives een file met dezelfde naam bevatten? Of, wat als je een file van 8GiB wilt wegschrijven terwijl je op elke disk nog maar 7GiB vrij hebt?

De beste optie IMO is al genoemd en dat is jezelf beschermen tegen verlies van een drive met een RAID 5 of beter.

[ Voor 12% gewijzigd door CyBeR op 30-10-2010 19:59 ]

[Sando]

deadinspace schreef op zaterdag 30 oktober 2010 @ 16:55:
Maar hou er rekening mee dat het niet zo simpel is als "Je verliest deze en deze files, en verder is het allemaal happy". Je sloopt gewoon een grote hap uit je filesystem, en dat heeft zo zijn gevolgen.

Bedankt voor de info. Jammer dat dat recoveren zo een gedoe is. Ik snap het fragmentatieverhaal, maar de schijven worden alleen gebruikt voor media opslag, en dat komt er vrij lineair op. Misschien eens een paar incoming tegelijk, nou die komen dan samengevlochten over de fysieke drivegrens heen en zullen allemaal verloren gaan op de resterende schijven, ook niet zo'n probleem.

Bij bepaalde RAID vormen en ik dacht voor het gemak - maar blijkbaar dus niet - bij LVM ook, wordt metadata enzo voor iedere schijf op alle schijven gezet, juist zodat er geen probleem is als er een schijf uitvalt.

Als je die disks niet vertrouwt zou ik daar allemaal niet aan beginnen, maar liever gewoon een filesystem per disk doen.

GH45T schreef op zaterdag 30 oktober 2010 @ 14:27:
Of in Windows je schijven mounten in een map als aanvulling op of in plaats van een schijfletter?

Dat doe ik hier zelf ook. Heb een RAID5 volume in mijn server, de losse harddisks heb ik in folders gemount staan zodat ik toch alles via één share kan benaderen.

itsme schreef op zaterdag 30 oktober 2010 @ 19:20:
Dit is denk ik het meest eenvoudige systeem, doet precies wat je wil toch?

Dat is nou precies hoet het standaard werkt in Linux. Dus dat is sowieso mijn 'terug bij af' situatie.

CAPSLOCK2000 schreef op zaterdag 30 oktober 2010 @ 19:06:
Wat jij wil heet unionfs. Er zijn verschillende versies van, oa een kernel implementatie en een fuse implementatie.

Dat klinkt inderdaad goed. Op het eerste gezicht is het vooral goed voor data onder één map krijgen (wat ik zoek) maar zit er geen dirigent ingebakken die bij het opslaan van bestanden automatisch een schijf aanwijst (wat ik ook zoek) van 'ga daar maar staan'. Ik ga me er straks eens meer in verdiepen.

jan99999 schreef op zaterdag 30 oktober 2010 @ 19:41:
Unraid is wat je nodig hebt
Maar wat jij wilt is eigenlijk raid 5 of 6(6 is beter) en daar boven op LVM.

Unraid schijnt heel traag te zijn, maar anyway, voor alle RAIDs moet je eigenlijk gelijke schijven hebben. Ik heb hier bijvoorbeeld een oude 80, 100, 120 en 160 GB drive.

CyBeR schreef op zaterdag 30 oktober 2010 @ 19:57:
Wat jij wilt is per disk een filesystem, en die dan weergeven alsof het één groot ding is.

Ja precies Maar toen ik dit topic maakte wist ik stiekem nog niet dat dat zo simpel niet was.

Het is ook wel lastig: wat als twee van die drives een file met dezelfde naam bevatten? Of, wat als je een file van 8GiB wilt wegschrijven terwijl je op elke disk nog maar 7GiB vrij hebt?

Als de volume manager in dat geval zou zeggen 'not enough space' dan was ik allang blij geweest.

[Sando]

Hey..

quote: http://www.unionfs.org/

Why to use AuFS instead of unionfs:

AuFS supports writable branch balancing. That means, you can setup
several partitions for writing and AuFS will split all new/modified
files between them, based on free disk space, existence of parent
directory, randomly, or combinations.

Eens kijken of dat iets is.

-edit-

Te ingewikkeld zo zonder documentatie. Ik kan bijna niets vinden.
https://help.ubuntu.com/c...sRootFileSystemOnUsbFlash

[ Voor 30% gewijzigd door Sando op 31-10-2010 02:28 ]

[Sando]

Ah ik ben al iets verder. Na een eeuw zoeken naar de juiste installatieprocedure blijkt dat het tegenwoordig ingebakken zit.

Ik krijg zo in ieder geval alle bestanden transparant in een enkele mount:
mount -t aufs -o dirs=/mnt/disk1=rw:/mnt/disk2=rw:/mnt/disk3=rw aufs /mnt/aufs

Maar bij een eerste test lijkt ie geen load balancing toe te passen. Hij schrijft gewoon alles naar de eerste schijf, ookal is er meer ruimte op de anderen.

-edit-

Als ie vol is gaat ie door op de volgende. Naja, ook goed. Load balancing is mooier omdat je dan ook damage balancing hebt, maar dit is een begin wat ongeveer is wat ik voor ogen had!

[deadinspace]

jan99999 schreef op zaterdag 30 oktober 2010 @ 19:41:
Unraid is wat je nodig hebt(dacht ik, misschien windows home server), hier kun je de opslag die jij wilt maken zo verdelen:

Hij was (in eerste instantie) helemaal niet op zoek naar RAID, dus ook niet naar unRAID

Sando schreef op zondag 31 oktober 2010 @ 01:30:
Bedankt voor de info. Jammer dat dat recoveren zo een gedoe is. Ik snap het fragmentatieverhaal, maar de schijven worden alleen gebruikt voor media opslag, en dat komt er vrij lineair op.

In theorie wel ja, maar je verwijdert straks ook weer media en zet er andere voor in de plaats. Fragmentatie krijg je altijd wel.

Bovendien heb je nog het probleem van parent directories die op een hele andere locatie kunnen staan. Wat nou als /media/films/the_ring.avi op de derde schifj valt, maar /media/films/ op de tweede schijf? Als de tweede schijf er uit klapt kun je The Ring niet meer benaderen, ook al stond die op een andere schijf. Ja, fsck weet hem waarschijnlijk wel terug te vinden, maar handig is het niet.

Bij bepaalde RAID vormen en ik dacht voor het gemak - maar blijkbaar dus niet - bij LVM ook, wordt metadata enzo voor iedere schijf op alle schijven gezet, juist zodat er geen probleem is als er een schijf uitvalt.

Wat voor metadata? Bij Linux software RAID heeft elke schijf wat RAID metadata, zodat de schijven tot een array te vormen zijn. Bij LVM is dat voorzover ik weet ook zo. Het verschil is dat het bij RAID niet uitmaakt dat er een schijf uitvalt omdat er redundantie is.

Als er bij RAID een schijf meer uitvalt dan de redundantie tegen beschermt dan is ook je hele array offline, net als bij LVM.

Filesystem metadata is iets waar zowel RAID als LVM zich niet mee bezig houden overigens, dat het bij RAID blijft werken als er een schijf uitvalt komt puur en alleen omdat er redundantie is voor alle data in het array.

Sando schreef op zondag 31 oktober 2010 @ 02:40:
Ah ik ben al iets verder. Na een eeuw zoeken naar de juiste installatieprocedure blijkt dat het tegenwoordig ingebakken zit.

Ik krijg zo in ieder geval alle bestanden transparant in een enkele mount:
mount -t aufs -o dirs=/mnt/disk1=rw:/mnt/disk2=rw:/mnt/disk3=rw aufs /mnt/aufs

Hmm, unionfs had ik nog niet aan gedacht, en aufs kende ik helemaal niet. Ziet er leuk uit!

Maar bij een eerste test lijkt ie geen load balancing toe te passen. Hij schrijft gewoon alles naar de eerste schijf, ookal is er meer ruimte op de anderen.

Probeer eens te spelen met de create=rr of create=mfs mountopties? Zie verder ook de mount.aufs manpage

[Sando]

Dit is echt fijn!

deadinspace schreef op zondag 31 oktober 2010 @ 17:52:
Wat voor metadata? Bij Linux software RAID heeft elke schijf wat RAID metadata, zodat de schijven tot een array te vormen zijn. Bij LVM is dat voorzover ik weet ook zo. Het verschil is dat het bij RAID niet uitmaakt dat er een schijf uitvalt omdat er redundantie is.

Metadata is vast het foute woord. Ik lees vanalles en onthoudt alleen de essentie. De inodes en weet ik wat er nog meer bij komt kijken om alles over de hele array en het filesystem te weten werdt opgeslagen op elke schijf, zodat deze informatie in ieder geval altijd nog beschikbaar is bij uitval. Ook als 2 van de 3 uitvallen en er is te weinig om nog iets te recoveren, dan zou dié informatie nog compleet zijn. Maarja, beetje klok klepel geef ik toe en ik heb er toch niets aan bij LVM (ook zonder stripes) dus ik ben het bij deze alweer vergeten.

deadinspace schreef op zondag 31 oktober 2010 @ 17:52:
Probeer eens te spelen met de create=rr of create=mfs mountopties? Zie verder ook de mount.aufs manpage

Weet je toevallig ook hoe ik zo'n aufs lijn in fstab moet zetten? Mag je daar wel het =-teken gebruiken?

mount:
mount -t aufs -o dirs=/mnt/disk1=rw:/mnt/disk2=rw:/mnt/disk3=rw aufs /mnt/aufs
fstab:
none /mnt/aufs aufs dirs=/mnt/disk1=rw:/mnt/disk2=rw:/mnt/disk3=rw 0 0 zo? -edit- ja dus

[deadinspace]

Sando schreef op dinsdag 02 november 2010 @ 08:23:
Metadata is vast het foute woord. Ik lees vanalles en onthoudt alleen de essentie. De inodes en weet ik wat er nog meer bij komt kijken om alles over de hele array en het filesystem te weten werdt opgeslagen op elke schijf, zodat deze informatie in ieder geval altijd nog beschikbaar is bij uitval. Ook als 2 van de 3 uitvallen en er is te weinig om nog iets te recoveren, dan zou dié informatie nog compleet zijn. Maarja, beetje klok klepel geef ik toe en ik heb er toch niets aan bij LVM (ook zonder stripes) dus ik ben het bij deze alweer vergeten.

Nouja, ik denk dat metadata wel het goede woord is, maar je hebt metadata op meerdere nivo's, en die nivo's zijn nogal losgekoppeld.

LVM maakt als het ware een virtuale harddisk aan bestaande uit die vier individuele disks aan elkaar, en ext3 komt dan op die virtuele harddisk. Maar ext3 heeft daar geen weet van. Het zou in principe inderdaad mogelijk zijn voor ext3 om de filesystem metadata op alle schijven op te slaan om zo een disk-uitval beter te tolereren, maar ext3 heeft niet eens door dat het over meerdere schijven verspreid wordt.

Weet je toevallig ook hoe ik zo'n aufs lijn in fstab moet zetten? Mag je daar wel het =-teken gebruiken?

Het vierde field in fstab is mount-opties, zie ook de manpage van fstab

[Verwijderd]

Om nog even terug te komen op UnRAID... UnRAID is geen echte RAID (5) oplossing, er wordt geen striping gebruikt. In een UnRAID server zit een parity drive en een of meerdere data drives die elk hun eigen ReiserFS filesysteem hebben.

Valt er een enkele schijf uit dan kan je de array gewoon opnieuw laten opbouwen zonder dataverlies. Vallen er twee of meer schijven uit dan verlies je hoogstens de data op deze schijven, de data op de andere schijven blijft toegankelijk. Met striping zou je alles kwijt zijn.

Je kan ook zonder probleem schijven van verschillende groottes er in hangen, de enige beperking is dat de pariteitsschijf minstens even groot moet zijn als de grootste dataschijf. Maar verder kan je werkelijk alles door elkaar gebruiken, een oude 8 GB PATA kan zonder problemen naast een 2 TB SATA II gebruikt worden...

Wat de snelheid betreft ben ik zeker niet ontevreden. Het is trager dan een echte RAID 5 oplossing omdat er geen striping toegepast wordt, maar in mijn setup (Athlon II dual core op 1,8 GHz geclockt, 1 GB DDR2 en vier Samsung 2 TB schijven en Gb ethernet) ligt de bottleneck bij de transfersnelheid van de harde schijven of (wat in mijn geval meer voorkomt) bij de lees- of schrijfsnelheid van de harde schijf in de clients.

[Noxious]

Interresant topic, ik ben ook al een tijdje op zoek naar zoiets.
Ik had een fileservertje met 1x160GB voor OS en 3x250GB in software RAID5 (Windows 2003 R2).
Dit is allemaal nog IDE en aan vervanging toe, daarnaast heeft de voeding het begeven dus is het hele zaakje offline (geen standaard ATX, is een Dell PowerVault 725n; moet nog bedenken hoe ik de data terug krijg maar dat is een ander verhaal).

Inmiddels zit ik te denken aan WHS omdat je daar lekker kan aangeven welke data je belangrijk vind, en hij er voor zorgt dat deze over meerdere disks is opgeslagen (afaik), maar eigenlijk zoek ik iets wat Linux based is en hetzelfde doet als WHS.

[Sando]

Ik heb geen verstand van Windows Home Server. Aufs is wel heel handig en zo makkelijk als "echo hoi", vreemd dat er zo weinig over te googlen is want ik weet nog steeds niet hoe ik branch balancing toe moet passen.

Anyway, als je Linux-based WHS-achtige toeren bent tegengekomen, wil je het dan ook even hier meedelen?

[Wolfboy]

Sando schreef op dinsdag 02 november 2010 @ 08:23:
Weet je toevallig ook hoe ik zo'n aufs lijn in fstab moet zetten? Mag je daar wel het =-teken gebruiken?

Zie /proc/mounts of /etc/mtab daarvoor

Werkt niet altijd (fuse wil het bijvoorbeeld niet altijd accepteren) maar verder kan je in principe de mounts makkelijk permanent maken door te kijken hoe ze daar gedefinieerd staan

[Sando]

Hey slim!
Ik had het al gefixt (bovenstaande post geëdit, de 'gegokte' lijn werkte gewoon) maar toch handig om te weten .:)

[deadinspace]

Verwijderd schreef op vrijdag 05 november 2010 @ 11:38:
Om nog even terug te komen op UnRAID... UnRAID is geen echte RAID (5) oplossing, er wordt geen striping gebruikt. In een UnRAID server zit een parity drive en een of meerdere data drives die elk hun eigen ReiserFS filesysteem hebben.

unRAID is natuurlijk wel echte RAID, maar dan RAID-4
De enige (best wel interessante) twist is dat ze een filesystem per (niet-parity) disk gebruiken.

[Verwijderd]

deadinspace schreef op zaterdag 06 november 2010 @ 22:07:
[...]

unRAID is natuurlijk wel echte RAID, maar dan RAID-4
De enige (best wel interessante) twist is dat ze een filesystem per (niet-parity) disk gebruiken.

Ik wou zeggen dat het geen RAID oplossing is zoals we RAID levels 0 tot 6 kennen. Bij RAID-4 wordt ook striping toegepast, als ik me niet vergis? Daarom is het voor mij ook echte geen RAID-4. Het blijft uiteraard een redundante array van inexpensive disks natuurlijk.

[Wolfboy]

Verwijderd schreef op woensdag 10 november 2010 @ 08:59:
[...]


Ik wou zeggen dat het geen RAID oplossing is zoals we RAID levels 0 tot 6 kennen. Bij RAID-4 wordt ook striping toegepast, als ik me niet vergis? Daarom is het voor mij ook echte geen RAID-4. Het blijft uiteraard een redundante array van inexpensive disks natuurlijk.

Je spreekt jezelf tegen. RAID-0 is ook niets anders dan striping namelijk

[deadinspace]

Verwijderd schreef op woensdag 10 november 2010 @ 08:59:
Ik wou zeggen dat het geen RAID oplossing is zoals we RAID levels 0 tot 6 kennen. Bij RAID-4 wordt ook striping toegepast, als ik me niet vergis? Daarom is het voor mij ook echte geen RAID-4. Het blijft uiteraard een redundante array van inexpensive disks natuurlijk.

Nouja, RAID-4 (op 4 disks) is als volgt:

disk 1	disk 2	disk 3	disk 4
data1-1	data2-1	data3-1	parity-1
data1-2	data2-2	data3-2	parity-2
data1-3	data2-3	data3-3	parity-3
data1-4	data2-4	data3-4	parity-4

Waarbij het array device dan de blokken data1-1, data2-1, data3-1, data1-2, data2-2, etc heeft.

Als je dan op het array drie filesystems wegschrijft interleaved met de stripe-size van het array, dan belandt elk filesystem netjes op één disk (voorbeeld met stripe size 64KB):

data1-1	data2-1	data3-1	data1-2	data2-2
1e 64KB van fs1	1e 64KB van fs2	1e 64KB van fs3	2e 64KB van fs1	2e 64KB van fs2

Als je het zo bekijkt, dan is unRAID prima te modelleren als RAID-4, je moet alleen wat moeilijker doen met de filesystems er boven op. (de ongelijke diskgroottes vegen we maar even onder het tapijt, maar da's op zich een triviale uitbreiding van RAID-4 die vast door sommige implementaties wordt ondersteund)

Sterker nog, ik vermoed dat dit schema (en dus unRAID) te implementeren is met behulp van Linux software RAID-4 en device-mapper zonder een regel code te schrijven

Wolfboy schreef op woensdag 10 november 2010 @ 10:12:
Je spreekt jezelf tegen. RAID-0 is ook niets anders dan striping namelijk

Hij zegt nergens dat iets met striping geen RAID kan zijn

Overigens is RAID-0 geen echte RAID. De R in RAID staat voor "redundant", en dat is RAID-0 niet. Sommige mensen spreken dan ook liever (en correcter) over een striped volume.

[leuk_he]

deadinspace schreef op woensdag 10 november 2010 @ 12:12:
[...]

Als je dan op het array drie filesystems wegschrijft interleaved met de stripe-size van het array, dan belandt elk filesystem netjes op één disk (voorbeeld met stripe size 64KB):

En dan is je parity array dus de opgetelde bottleneck geworden van alle andere FS? Dus als 1 van de 3 FS 100% io gebruikt op zijn disk zijn voor writes alle FS overbelast, want de parity zit dan ook op 100% io?

Maar als oefening kan het denk ik wel.

Is me ook een raadsel waarom je dan 3 file system zou willen.
-Voor write load heb je dus een bottleneck
-Voor quota heeft linux al een quota module toch?
-Voor read performance wil de stripe gebruiken over meerdere disks, netzo als voor write.
-1 Groot FS geeft meer flexibiliteit, zeker in combinatie met softlinks.

[deadinspace]

leuk_he schreef op woensdag 10 november 2010 @ 13:59:
En dan is je parity array dus de opgetelde bottleneck geworden van alle andere FS? [...] Is me ook een raadsel waarom je dan 3 file system zou willen.

Eh ja, da's het idee achter unRAID heh. Zie ook de rest van de discussie

Een reden waarom je het zou willen is dat de failure mode minder dramatisch is dan die van andere RAID-vormen.

[leuk_he]

deadinspace schreef op woensdag 10 november 2010 @ 15:24:
[...]

Een reden waarom je het zou willen is dat de failure mode minder dramatisch is dan die van andere RAID-vormen.

Dat had ik net gemist.

[Sando]

Na een reboot kom ik er pas achter, fstab werkt niet mee.
Geen foutmelding of iets, maar /mnt/aufs is leeg.

Als ik dan als root gewoon doe:
# umount aufs
# mount -a

Dan werkt het wel gewoon!
(met mount -a testte ik fstab, daarom dacht ik dat het gewoon werkte.)

Iemand enig idee waarom mijn aufs niet automatisch wil mounten maar exact de zelfde fstab het handmatig wel doet?

Mijn testopstelling:

code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc      nodev,noexec,nosuid 0       0
UUID=........-....-....-....-............ /               ext4    errors=remount-ro 0       1
UUID=........-....-....-....-............ /home           ext3    defaults          0       2
UUID=........-....-....-....-............ /red            ext3    defaults          0       2

UUID=........-....-....-....-............ /mnt/red200     ext3    defaults          0       2
UUID=........-....-....-....-............ /mnt/red160     ext3    defaults          0       2
none            /mnt/aufs       aufs      dirs=/mnt/red200=rw:/mnt/red160=rw        0       0

UUID=........-....-....-....-............ none            swap    sw                0       0

[MartinMeijerink]

en als je er auto bij zet?
dus zo:

code:

none            /mnt/aufs       aufs      dirs=/mnt/red200=rw:/mnt/red160=rw,auto   0

[Wolfboy]

Misschien dat je systeem het op een of andere manier parallel wil mounten? Wat natuurlijk niet lukt omdat /mnt/red200 nog niet gemount zou zijn.

Als laatste redmiddel zou je het nog in je /etc/rc.local kunnen zetten.

[xer]

Heb dit topic doorgelezen, en aufs lijkt voor mij een oplossing.
Ik draai Debian Lenny.
maar krijg aufs niet werkend

heb het volgende gedaan
aptitude install aufs-modules-2.6-amd64
aptitude install aufs-tools.

Als ik een mount probeer bv:
mount -t aufs -o dirs=/store/store1/video=ro:/store/store2/video=ro aufs /store/video

krijg ik
mount: unknown filesystem type 'aufs'

Heb via google een oplossing proberen te vinden, maar is nog zeer weinig over aufs te vinden.

[deadinspace]

xer schreef op vrijdag 12 november 2010 @ 15:45:
krijg ik
mount: unknown filesystem type 'aufs'

Wat zeggen

dpkg -l aufs-modules\* linux-image\*

en

uname -a

?

Heb via google een oplossing proberen te vinden, maar is nog zeer weinig over aufs te vinden.

"Nog?" Aufs is unmaintained (staat gewoon op de homepage), dus dat zal alleen maar erger worden

[xer]

deadinspace schreef op vrijdag 12 november 2010 @ 16:13:
[...]

Wat zeggen

dpkg -l aufs-modules\* linux-image\*

un aufs-modules <none> (no description available)
ii aufs-modules-2 2:2.6.26-6+len Stackable unification filesystem for Linux 2
ii aufs-modules-2 2.6.26+0+20080 Stackable unification filesystem for Linux 2
un linux-image <none> (no description available)
un linux-image-2. <none> (no description available)
ii linux-image-2. 2.6.26+17+lenn Linux 2.6 image on AMD64
ii linux-image-2. 2.6.26-13lenny Linux 2.6.26 image on AMD64
ii linux-image-2. 2.6.26-25lenny Linux 2.6.26 image on AMD64
ii linux-image-2. 2.6.30-6 Linux 2.6.30 image on AMD64

en

uname -a

?

2.6.30-1-amd64

"Nog?" Aufs is unmaintained (staat gewoon op de homepage), dus dat zal alleen maar erger worden

en

modprobe aufs

FATAL: Module aufs not found.

[deadinspace]

xer schreef op vrijdag 12 november 2010 @ 16:53:
un aufs-modules <none> (no description available)
ii aufs-modules-2 2:2.6.26-6+len Stackable unification filesystem for Linux 2
[...]

Zou je voortaan zulk soort output tussen [cmd] of [code] tags willen zetten? Dit is namelijk niet al te leesbaar

2.6.30-1-amd64

Ahja, da's niet zo raar dan; aufs-modules-2.6.26-2-686 bevat modules voor 2.6.26 (de Lenny kernel), en jij draait geen 2.6.26. Waar heb je die 2.6.30 vandaan?

[xer]

Waarschijnlijk heb ik deze ooit geinstalleerd om aan een dependency te voldoen, hoe ik hier aan kwam weet ik niet meer, mogelijk gewoon via aptitude?
Is het save om te downgraden naar 2.6.26, en hoe kan ik dat het best doen?

edit:
heb grub's menu.lst aangepast en nu wordt 2.26.2 geladen

Na een reboot en na een modprobe aufs kon ik aufs gebruiken.

Bedankt voor het duwtje naar de goede richting.

[ Voor 29% gewijzigd door xer op 12-11-2010 19:35 ]

[deadinspace]

xer schreef op vrijdag 12 november 2010 @ 19:14:
Waarschijnlijk heb ik deze ooit geinstalleerd om aan een dependency te voldoen, hoe ik hier aan kwam weet ik niet meer, mogelijk gewoon via aptitude?

2.6.30 zit helemaal niet in Lenny, dus "gewoon" via aptitude zal wel niet

[lezzmeister]

Een groot fs om alles op een hoop te mikken en toch enige redundantie klinkt reuze interessant.
Kan ik gewoon zonder zorgen een schijf of 4 a 5 in mijn workstation mikken.
(Ja ja, ik draai ook gewone backups.)

Ik kwam in mijn zoektocht voor iets soortgelijks langs Raid 1E. Gewoon doorschrijven en zolang twee naast elkaar gelegen schijven de geest niet geven, is je data veilig. Dat zou in theorie moeten werken tot je aan het laatste stuk ruimte van de grootste schijf komt. (Toch?) Dan heb je in ieder geval niet een schijf als bottleneck als bij Raid 1E

Bestaat er niet iets als unRaid in een gratis variant ergens?

Iets anders, voor als je heel creatief ben: maak een zooi VM's aan, één voor iedere schijf, en dan deze route te gaan:http://en.wikipedia.org/wiki/Redundant_Array_of_Inexpensive_Nodes
Maar toen ik met dat idee kwam heb ik het ook gelijk laten gaan, want om dat werkend te krijgen ben je nog wel wat verder, en wie weet wat de aanslag op performance zal zijn.
Echt eenvoudig ziet het er niet uit: http://sourceforge.net/ap...dex.php?title=Screenshots
(Dat is een screenie van Chordless, een voorbeeld van een Rain.)

Ik vraag me af hoeveel moeite het is om het principe van een Rain in LVM te zetten....
Al zijn mijn programmeer skills compleet ontoereikend, dus zal ik er niet aan beginnen.

[xer]

deadinspace schreef op zaterdag 13 november 2010 @ 00:01:
[...]

2.6.30 zit helemaal niet in Lenny, dus "gewoon" via aptitude zal wel niet

klopt, testing stond in /etc/apt/sources.list
Volgens de changelog, is vanaf versie 2.6.31-1, aufs2 in de kernel gebakken

[ Voor 13% gewijzigd door xer op 13-11-2010 10:17 ]

[Sando]

MartinMeijerink schreef op donderdag 11 november 2010 @ 19:42:
en als je er auto bij zet?
dus zo:

code:

none            /mnt/aufs       aufs      dirs=/mnt/red200=rw:/mnt/red160=rw,auto   0

Wolfboy schreef op donderdag 11 november 2010 @ 21:50:
Als laatste redmiddel zou je het nog in je /etc/rc.local kunnen zetten.

Dank jullie, ik probeer de auto, bij de volgende boot weet ik of ik moet gaan kijken wat [b[rc.local[/] is.

lezzmeister schreef op zaterdag 13 november 2010 @ 03:14:
Ik kwam in mijn zoektocht voor iets soortgelijks langs Raid 1E. Gewoon doorschrijven en zolang twee naast elkaar gelegen schijven de geest niet geven, is je data veilig. Dat zou in theorie moeten werken tot je aan het laatste stuk ruimte van de grootste schijf komt. (Toch?)

Volgens mij moeten alle schijven evengroot zijn, zeker voor die veiligheidsredundatie. Daarom is RAID zo irritant voor simpele "op een hoop gooi" oplossingen.

deadinspace schreef op vrijdag 12 november 2010 @ 16:13:
[...]
"Nog?" Aufs is unmaintained (staat gewoon op de homepage), dus dat zal alleen maar erger worden

Ja, onbegrijpelijk. Het is superhandig en heeft features die ik gewoon niet eens aan de praat krijg omdat ik geen documentatie kan vinden over geavanceerde features.
Bovendien wordt dit gewoon op alle livecd's gebruikt om een filesystem te krijgen waar bestanden in squashfs read-only zijn en alle schrijfacties (inclusief die van read-only bestanden) op de 'ramdrive' worden uitgevoerd.

[deadinspace]

lezzmeister schreef op zaterdag 13 november 2010 @ 03:14:
Een groot fs om alles op een hoop te mikken en toch enige redundantie klinkt reuze interessant.

Ja, dat heet nou RAID

Ik kwam in mijn zoektocht voor iets soortgelijks langs Raid 1E.

Hmm, ik zie de meerwaarde van 1E niet zo... Doe dan RAID-5 of RAID-6?

Tenzij je echt write performance nodig hebt, maar dan nog...

Iets anders, voor als je heel creatief ben: maak een zooi VM's aan, één voor iedere schijf, en dan deze route te gaan:http://en.wikipedia.org/wiki/Redundant_Array_of_Inexpensive_Nodes

Da's wel een heel omslachtige manier om RAID te doen

xer schreef op zaterdag 13 november 2010 @ 08:08:
klopt, testing stond in /etc/apt/sources.list

Gezellig, dan draai je half testing, half stable

[lezzmeister]

deadinspace schreef op zaterdag 13 november 2010 @ 19:54:

Ja, dat heet nou RAID

Ja en nu met schijven van verschillende grootte die dan wel int geheel gebruikt worden wijsneus.
Ja dat unRaid, maar is daar een software implementatie van?
Als in: gratis verkrijgbaar zonder grenzen voor de particulier?

Hmm, ik zie de meerwaarde van 1E niet zo... Doe dan RAID-5 of RAID-6?

Tenzij je echt write performance nodig hebt, maar dan nog...

Ja dat vraag ik me dus ook af. De echte meerwaarde van Raid 1E. Maar daar kwam ik dus bij doordat ik ook een op-een-hoop-gooi fs zocht ooit. En nog steeds wel. Was een of ander figuur met een paar vage patches die dus softwareraid 1E toelieten met schijven van verschillende grootte. Maar het zal geen succes geweest zijn, want die pagina is allang weer onbereikbaar.

Echt benches om het verschil in lezen aan te tonen zijn er niet een twee, geen recente in ieder geval. Al zal het wel uitmaken in het geval je een schijf verliest. 1E zal dan wat vlugger blijven. Denk ik.

Da's wel een heel omslachtige manier om RAID te doen

Maar als dat werkt....
Schijven van verschillende grootte, die zichzelf aan en afmelden bij het toevoegen en uitvallen. En toch heb je redundantie.
Ideaal.

Nu ik erover denk, toch maar ff snel Virtualbox er weer op gooien. Eens kijken ik iets kan vogelen.
Als ik per VM heel weinig resources kan gebruiken, kan het zo maar werken.
Ik heb het eerder gezien. Een crea-bea buurjongen had behoefte aan Raid 5, maar had slecht Vista Home Premium. Dus wat had hij gedaan? Een virtual machine met daarop OpenFiler. En zo had hij toch Raid 5 opslag. Moet ook wat uitgebreider kunnen.

[jan99999]

Raid 5 in een virtuele omgeving heeft natuurlijk geen zin.
Bij een crash op je echte hd dan is je data weg, en repareren kun je dit niet.

[CAPSLOCK2000]

Het nut van RAID1E / RAID10F*

Denk eerst aan de voordelen van RAID0, namelijk dat je lees en schrijfsnelheid effectief verdubbelt.
Het heeft echter ook een groot nadeel, namelijk dat als je 1 schijf verliest je alles kwijt bent.

Pak twee harde schijven, en hak ze allebei in twee helften.
Bouw van de eerste twee helften een RAID0.
Je hebt nu alle snelheidsvoordelen van RAID0, maar ook de nadelen.

Maar je hebt nog twee halve disks over. Dus daar bouw je nog een RAID0 van en gebruikt die als Mirror voor de eerste RAID1. Als je de schijven in omgekeerde volgorde in de mirror zet dan staat op iedere schijf een volledige kopie van de data.

Je eerste reactie is misschien "uiteindelijk moet je toch alles twee keer schrijven, dat kan toch niet sneller zijn":

Je vergeet dan dat HD's niet overal even snel zijn. Aan de buitenkant zijn ze veel sneller dan aan de binnenkant. Als bereidt bent om een klein beetje veligheid op te geven kun je daar gebruik van maken. Als je accepteert dat een actie "klaar" is zodra het op 1 schijf staat (dat is dan op het snelle stuk). Het duurt nog iets langer voor de backup ook is opgeslagen, maar je programma hoeft daar niet op te wachten.

Er is nog een tweede voordeel. Bij het lezen gebruik je alleen de snelle helft van de schijf. Hierdoor hoef je leesarm minder ver te reizen en zullen je seektijden verbeteren.

Illustratie:

Stel we willen "A B C D E F" opslaan:

raid1:
schijf 1: A B C D E F
schijf 2: A B C D E F

raid0:
schijf 1: A C E
schijf 2: B D F

raid 10f:
schijf 1: A C E B D F
schijf 2: B D F A C E

Zoals je ziet bevatten onder raid10f/raid1e beide schijven alle data, maar in een andere volgorde dan normale
RAID1.


Als er een schijf stuk gaat dan is RAID10F overigens een stuk langzamer. Opeenvolgende bloks staan namelijk niet achter elkaar op de schijf. De ene helft staat aan het begin, de andere helft aan het einde.


* voor zover ik het begrijp zijn raid 1E en raid 10F verschillen alleen in het gebruik van een oneven danwel even aantal disks

[Sando]

MartinMeijerink schreef op donderdag 11 november 2010 @ 19:42:
en als je er auto bij zet?

Yep, werkt!
What just hapened?

Betreft de RAID discussie, het gaat hier vooral om een grote storage heap die je bij wijze van spreken kan uitbreiden met elke schijf die uit je neus komt vallen. En zonder enige vorm van gedoe een rotte schijf in de prullenbak kan gooien. Oké, *ploep* paar DV bandjes die je opnieuw moet capturen of 10 HD films kwijt, maar de aufs wordt er verder niet warm of koud om.

Video capture, video recording, media downloads, dat soort spul. Die snelheid is helemaal niet nodig. Mijn traagste schijf in de AUFS-klont schrijft met 40 MB/s en zo snel is mijn netwerk of firewire toch niet.

Het zou mooi zijn als iedereen gecharmeerd wordt van het aufs-gemak omdat het niet het lof krijgt wat het verdient Kijk maar naar de hoeveelheid info die je kan vinden.

Ander handigheidje: Oude Nokia Symbian phone met een aantal gigs intern geheugen en een aantal gigs op een mmc kaartje. In plaats van de muziek die je erop wilt zetten handmatig te verdelen over de twee usb-storages kan je ook gewoon een aufsje maken en alles daarop zetten.

[lezzmeister]

jan99999 schreef op zondag 14 november 2010 @ 02:39:
Raid 5 in een virtuele omgeving heeft natuurlijk geen zin.
Bij een crash op je echte hd dan is je data weg, en repareren kun je dit niet.

Er vanuit gaande dat hij maar een harde schijf gebruikte natuurlijk...

En ik heb geprobeerd een RAIN virtueel te draaien met maar mager succes. Het werkt in beginsel wel, maar echt goed loopt het niet. Ik kom met 8GB schromelijk ram tekort.
Het zou dus wel vloeiend moeten kunnen werken, maar dan moet je dus wel met zeer kleine en minimale systemen in een VM gaan draaien. Minimale embedded systemen zou dan nog het beste zijn, en dan zorgen dat ze niks van de schijf zelf gaan cachen.
Maar een 160, 250 en 500 GB schijf draaien gewoon goed, en eentje eruit rukken kan gewoon. Maar het zal pas echt goed gaan bij een hele verzameling. Eerstvolgende aankoop word een leuke hotswap bay. Ik zie hier wel potentie in. Kan ook niks worden natuurlijk.

[Olaf van der Spek]

Sando schreef op zondag 14 november 2010 @ 14:29:
Het zou mooi zijn als iedereen gecharmeerd wordt van het aufs-gemak omdat het niet het lof krijgt wat het verdient Kijk maar naar de hoeveelheid info die je kan vinden.

Het is inderdaad vreemd dat zoiets niet goed ondersteund wordt, ook onder Windows. Wie heeft er niet meerdere HDDs? Handmatig bestanden en directories verdelen is gewoon niet handig. Paden die afhangen van de fysieke lokatie ook niet.

[deadinspace]

lezzmeister schreef op woensdag 17 november 2010 @ 18:12:
En ik heb geprobeerd een RAIN virtueel te draaien met maar mager succes. Het werkt in beginsel wel, maar echt goed loopt het niet. Ik kom met 8GB schromelijk ram tekort.

Hoezo RAM tekort? Als je elke VM 512 MB geeft (dat zou meer dan zat moeten zijn) kun je zonder problemen 14 VMs draaien...

Maar ik hoop dat je je realiseert dat je met RAIN op VMs op een enkele host niks opschiet buiten een leerervaring en wat hack value? Het beste wat je namelijk kan bereiken is hetzelfde als RAID.

[lezzmeister]

Maar dan wel met schijven die zichzelf aan en afmelden en die van verschillende grootte werken prima samen.
Eigenlijk UnRaid, alleen is die oplossing er niet voor thuisgebruik.
En dan nog, met UnRaid is de pariteitschijf de bottleneck, dus dan zou je die in Raid 1 moeten kunnen zetten, en dan split seeks erop kunnen doen(bijvoorbeeld). Werkt vast vlugger.

[deadinspace]

lezzmeister schreef op donderdag 18 november 2010 @ 15:45:
Maar dan wel met schijven die zichzelf aan en afmelden en die van verschillende grootte werken prima samen.

Mja, maar wat ik van chordless zie is dat hij alle data repliceert, dus dat maakt het een soort RAID-1, dus daar verlies je veel opslagcapaciteit. Is de grootte die je verliest door ongelijke schijven dan groter?

Eigenlijk UnRaid, alleen is die oplossing er niet voor thuisgebruik.

Hoezo is unRAID er niet voor thuisgebruik?

En dan nog, met UnRaid is de pariteitschijf de bottleneck

En jij denkt dat je met Chordless in VMs ook maar in de buurt gaat komen van de performance van unRAID?

[lezzmeister]

Niet uitgebreid getest, maar je moet wel ff de tijd geven om the syncen en te doen.
Maar je verliest wel meer ruimte dan Raid 1, voor zover ik het heb "getest".
unRaid is echt een produkt van Lime Tech en dat bedrijf alleen. Het is wel voor thuis, maar dan zit je een beetje vast aan hoe zij het willen.
Als het nu een standaard Raidlevel in de kernel was(bijvoorbeeld). Dat is veel makkelijker aan te passen aan wat je wil.
En dan nog zou het fijn zijn om de pariteitschijf in Raid 1 te zien bij echt grote verzamelingen harde schijven, die word bij iedere write namelijk weer belast, en die zal waarschijnlijk als eerste de geest geven, ook bij rebuilden van een schijf zal die het zwaar hebben en lezen van 2 pariteitsschijven zal ook wel vlugger gaan(mits goed geimplementeerd). En dan zit je nog met schijven van verschillende grootte, alsnog een voordeel ten opzichte van Raid6.
Wat waarschijnlijk ook wel is op te lossen door 2 unRaid arrays in een pool te mikken, maar dan nog.

Edit: Zit ook 1 hele dikke bug in VirtualBox(in het netwerkgedeelte, denk ik). Dat naast de bridging die al niet lekker gaat. Dat zal ook zorgen voor een paar rare dingen die ik tegenkom.

[ Voor 8% gewijzigd door lezzmeister op 19-11-2010 15:26 ]

[deadinspace]

lezzmeister schreef op vrijdag 19 november 2010 @ 15:14:
unRaid is echt een produkt van Lime Tech en dat bedrijf alleen. Het is wel voor thuis, maar dan zit je een beetje vast aan hoe zij het willen.

Da's waar. Het is sowieso proprietary software, wat voor mij al reden genoeg zou zijn om het niet te gebruiken.

En dan nog zou het fijn zijn om de pariteitschijf in Raid 1 te zien bij echt grote verzamelingen harde schijven, die word bij iedere write namelijk weer belast, en die zal waarschijnlijk als eerste de geest geven

Da's nogal de vraag. Google vond geen bijzonder sterke correlatie tussen gebruiksintensiviteit en levensduur.

en lezen van 2 pariteitsschijven zal ook wel vlugger gaan(mits goed geimplementeerd).

Dat is nutteloos. Bij een rebuild, of bij het draaien in degraded mode moeten alle schijven uitgelezen worden. Een snellere parity-disk(-array) helpt dus niets, aangezien de andere schijven dan de bottleneck zijn.

[heuveltje]

Beetje vreemde eend in de bijt (maar wel lekker)
Flexview, (eigenlijk onderdeel van flexraid maar ook los te gebruiken)
Dit geeft je de mogelijkheid om meerdere disken/folders samen te voegen en als 1 disk te gebruiken.
Zonder iets aan de partities/disken te wijzigen.

Gebruik het nu een tijdje om 10 disken als 1 netwerkshare aan mijn popcornhour aan te bieden.
Werkt vrij netjes

[Sando]

aufs ftw!

Volgens mij heb ik nu de perfecte aufs mountregel voor in fstab. Na afentoe rare acties (volle disk terwijl dat niet zo is enzo) en wat trial en error hier mijn mountregel voor de slechtst gedocumenteerde coolste feature.

Ik heb verschillende schijven gemount in /mnt en die wil ik allemaal samen in /red mounten.

code:

none  /red  aufs  br=/mnt/red400=rw:/mnt/red300=rw:/mnt/red200=rw:/mnt/red160=rw,create=mfs,cpup=bup,auto  0 0

• =rw -> Categorie duh, writable maken. (default = readonly voor alles behalve de eerste branche)
• create=mfs -> bestanden worden created op de schijf met most free space. (default = highest parent)
• cpup=bup -> kan een bestand niet geschreven worden, wordt de eerst volgende branch gebruikt. CopyUpPolicy=Bottom-Up-Parent. (default = highest parent)
• auto -> man mount: "Can be mounted with the -a option." (anders wordt ie niet gemount bij het booten.)
• br= ipv dirs= -> Categorie voor de zekerheid; Ik kwam een distro tegen waarin dirs niet werkte maar br(anches) wel. (Let op: br gebruikt dubbele punt ipv puntkomma)

Bron: http://aufs.sourceforge.net/aufs.html

Note: Het lijkt erop dat aufs de group het zelfde als owner maakt, ookal is dat in de echte branches niet zo. Met dat in het achterhoofd krijg je minder hoofdpijn als je je webserver/fileserver/torrentclient/backupstorage configureert.

[ Voor 8% gewijzigd door Sando op 16-01-2011 20:02 ]

[jan99999]

http://romanrm.ru/en/mhddfs

http://manpages.ubuntu.com/manpages/lucid/man1/mhddfs.1.html
Lees onderaan, je moet file systeem samenvoegen die ook de grootte of ruimte kunnen weergeven/doorgeven.

WARNINGS
The filesystems are combined must provide a possibility to get their
parameters correctly (e.g. size of free space). Otherwise the writing
failure can occur (but data consistency will be ok anyway). For example
it is a bad idea to combine a several sshfs systems together.

[ Voor 121% gewijzigd door jan99999 op 30-01-2011 17:10 ]

[Sando]

Hey, nog een! Goed gevonden.

Ik zie alleen de meerwaarde boven aufs niet, aufs heeft meer opties.
En ik weet niet zeker of ik je zin snap.

[lamko]

Het voordeel hiervan is dat het juist hiervoor speciaal gemaakt is waardoor het een simpelere oplossing is.

[xer]

Bedankt voor de mhddfs tip.

Nog een voordeel van mhddfs t.o.v. aufs.
Mhddfs ondersteund NFS.
Aufs ook wel, maar hiervoor is NFS ondersteuning niet in de standaard debian kernel opgenomen.

[Sando]

lamko schreef op maandag 31 januari 2011 @ 15:15:
Het voordeel hiervan is dat het juist hiervoor speciaal gemaakt is waardoor het een simpelere oplossing is.

En aufs was gemaakt om mp3's af te spelen?
Ik ben niet zo gemeen als deze flauwe reactie hoor maar ik snap het voordeel nog steeds niet.

xer schreef op donderdag 17 februari 2011 @ 18:02:
Nog een voordeel van mhddfs t.o.v. aufs.
Mhddfs ondersteund NFS.

Dat klinkt dan wel weer cool! Maar tussen twee haakjes:
Ik heb een handvol keren een poging ondernomen om NFS te 'leren' maar nooit een artikel kunnen vinden die het niet overbodig ingewikkeld deed lijken. Daarom deel ik - zelfs in een linux only netwerk - bestanden gewoon met SAMBA omdat, hoewel ook niet al te simpel op te zetten - daar tenminste abcdocumentatie over te vinden is.

[lamko]

NFS is juist simpeler dan samba vanaf de console dan !

Dit in /etc/exports stoppen:

/export 192.168.1.0/24(rw,fsid=0,insecure,no_subtree_check,async)
/export/Data 192.168.1.0/24(rw,nohide,insecure,no_subtree_check,async,anonuid=1000)

[Sando]

Handmatig IP adressen intiepen is zooo 29 oktober 1969.

Maar goed, als je een guide for noobs hebt, schroom niet om de url even te posten want als de ingegroeide angst voor NFS makkelijk weg te nemen is dan probeer ik het graag nog een keertje.

[Sando]

Lastig. mhddfs is niet beter dan aufs. Het heeft voor- en nadelen.

+ disk-free telt alles bij elkaar op. In aufs zie je df van de schrijfschijf (afhankelijk van opties)
+ bij disk-full fout zal mhddfs het op een andere schijf proberen en aufs niet.
- aufs heeft veel meer opties voor wat wanneer op welke schijf zetten
- aufs ondersteunt meerdere read-only media, welke bewerkt kunnen worden door op een hogere schijf te schrijven

[ Voor 67% gewijzigd door Sando op 21-02-2011 22:15 ]

[xer]

Sando schreef op maandag 21 februari 2011 @ 22:01:
Lastig. mhddfs is niet beter dan aufs. Het heeft voor- en nadelen.

+ disk-free telt alles bij elkaar op. In aufs zie je df van de schrijfschijf (afhankelijk van opties)
+ bij disk-full fout zal mhddfs het op een andere schijf proberen en aufs niet.
- aufs heeft veel meer opties voor wat wanneer op welke schijf zetten
- aufs ondersteunt meerdere read-only media, welke bewerkt kunnen worden door op een hogere schijf te schrijven

Ben het met je eens dat aufs een paar grote voordelen heeft, helaas lijkt het erop dat aufs o.a. bij debian niet meer in de nieuwe releases wordt opgenomen.
Was het niet dat NFS suport niet in in de kernel was opgenomen , had ik nog steeds aufs gebruikt.

[Sando]

Zijn er nog nieuwe ontwikkelingen op dit gebied?

Vooralsnog zit aufs gewoon in Debian. Ik kan geen duidelijke artikels vinden over of het nu wel of niet geschrapt wordt. Sterker nog, ik krijg de indruk dat aufs in de meeste distro's zit. Nog sterker: Zoals xer eerder aangaf zit het inmiddels in de kernel ingebakken (debian iig). Geen module.

Volgens mij is het enige noemenswaardige:
[list]
• aufs (begon als ufs fork)
• mhddfs
• UnionFS (ufs)

en aufs steekt er bovenuit.

Het zou mooi zijn als je gewoon een aantal sata-poorten kon aanwijzen waarbij hotpluggable schijven ook automatisch aan een mount worden toegevoegd of verwijderd.

Nog steeds vermoed ik dat er betere truuks voor het zelfde zijn omdat er zo weinig over te vinden is, terwijl dit echt loeihandig is. Ik knutsel binnenkort een thuisservertje in elkaar, dus ik dacht: Nog even een balletje opgooien, want dit moet toch haast veel breder toegepast worden dan de documentatie doet vermoeden? Als je aan een serverbak denkt waar gewoon een hoop media op moet staan. Een youtube ofzo. Dan moet je toch gewoon een lading sata-schijven op één unified mountpoint hebben zitten, die bij storing zonder gezeur vervangen kunnen worden als een gloeilamp?

xer schreef op zondag 27 februari 2011 @ 10:09:
[...]
Was het niet dat NFS suport niet in in de kernel was opgenomen , had ik nog steeds aufs gebruikt.

Hoe bedoel je dat eigenlijk precies?