Ubuntu: Hvordan lage software Raid0 eller JBOD?

[Simen1]

Jeg har en maskin med følgende disker:

 

80 GB SSD

1,5 TB HDD

1,5 TB HDD

 

På SSDen har jeg installert Ubuntu 10.10. Harddiskene er tomme, men de skal bli husets backupmaskin (altså kopi av det som ligger lagret andre steder). Jeg ønsker å sette opp de to harddiskene med software JBOD eller Raid0 slik at de blir ett lagringsområde med 3 TB. Disken skal mappes fra andre Windows- og Ubuntumaskiner i huset. Første utfordring er å sette opp software JBOD eller Raid0. Hvordan gjør jeg det?

[Sokkalf™]

Jeg har alltid gjort dette under installasjon (usikker på om Ubuntu-installeren lar deg gjøre dette, men det er lett i Debian og Fedora).

 

Det er etter min oppfatning mye lettere enn å sette det opp manuelt i etterkant.

 

Siden jeg ikke har gjort dette manuelt (eller, ihvertfall ikke husker i detalj hvordan jeg gjorde det), så kan jeg ikke beskrive det så nøye.

 

Ihvertfall, for JBOD kan lvm løse problemet ditt.

For software RAID0 er mdadm tingen.

 

For mdadm må man ihvertfall lage en partisjon på hver disk av type "RAID Autodetect" (mener det er partisjonstype 0xFD).

 

Deretter mener jeg det står greit forklart i manualen til mdadm hvordan man oppretter et raid med level=0.

[sablabra]

Personlig ville jeg aldri brukt raid0 som backup-løsning, da du har ingen "redundancy" dersom en disk skulle feile. Ville sterkt vurdert å skaffe en ekstra 1,5 TB disk og satt opp i raid5 eller tilsvarende (da vil du fortsatt få 3 TB lagringsplass, og det skal gå greit å bygge opp arrayet dersom en disk skulle feile).

 

Når det gjelder fremgangsmåten for å sette det opp ser det ut til å være dekket i ubuntu wikien: https://wiki.ubuntu.com/Raid

Jeg synes dog artikkelen var dårlig, denne på arch wikien forklarer hvert skritt mye bedre: https://wiki.archlinux.org/index.php/Installing_with_Software_RAID_or_LVM

 

Lykke til

[Simen1]

Takk for tips Sokkalf. Jeg skal sjekke ut mdadm og lvm.

 

sablabra: Jeg satser på full redunsans og er fornøyd med sikkerheten ved å ha ting lagret på to steder samtidig (hver sin PC i samme hus, men jeg planlegger å flytte den ene hjemmefra til kontoret så jeg ikke mister begge kopiene dersom lynet slår ned eller huset brenner).

 

Å kjøre Raid5 på en eller begge stedene synes jeg blir overkill for mitt bruk. Skulle denne maskina mot formodning eksplodere så har jeg jo alt lagret på originalplassene uansett.

 

Tusen takk for linkene.

[kpolberg]

https://www.diskusjon.no/index.php?showtopic=1058413&view=findpost&p=12867174

 

=)

 

Forøvrig er det ofte en fordel å legge LVM oppå md devicen. og ikke bruke all plassen samtidig, selve filsystemet er det enkelt å utvide.

 

Eller du kan bruke http://romanrm.ru/en/mhddfs, den bruker begge diskene i ett slags jbod/raid0 hvor du fremdeles kan montere opp diskene enkeltvis og bare miste "halvparten" av dataene i tilfelle en av diskene skulle ryke.

[Simen1]

Sistnevnte der virker genial. Takk!

 

Redigert: Det er vel ikke noe 2 TiB-problematikk med noen av disse anbefalingene?

Endret 2. februar 2011 av Simen1

[Del]

Drit i LVM og mdadm, gå for btrfs. Du finner alt du trenger her:

http://www.linux.com/learn/tutorials/371623:weekend-project-get-started-with-btrfs

si ifra hvis vi kan bidra med noen kommandolinjer.

[Sokkalf™]

Er btrfs ansett for å være "trygt" nå?

[Del]

Hvis Raid0 er trygt nok... Chris Mason lovte for en uke siden at han jobber full spiker med btrfsck, så det kommer sikkert på plass innen Simen1 sitt array eksploderer

[Lycantrophe]

Jeg bør altså bruke btrfs fremfor raid1 når jeg skal sette opp filserveren min (2x2TB-disker)? Hvordan er lesingen av disse fra f.eks Arch (over nettverk)?

[HawP]

Da går det jo via NFS eller Samba (om du velger den "vanlige" løsningen), så da holder det om Arch har støtte for den av disse du bruker.

[Lycantrophe]

NFS er vel det optimale linux -> linux, så jeg går vel for det.

[Del]

Btrfs er suverent enklere enn LVM+mdam+XFS, med det meste av funksjonaliteten. Utrolig morsomt å følge med på mailinglisten til btrfs, der går det unna. Ved neste ubuntu tror jeg den kan friskmeldes også for profesjonelt bruk, med mindre man er svært konservativ.

[kpolberg]

For en backup server ville jeg _aldri_ brukt ett filsystem som ikke anses som prod klart. I tillegg virker btrfs foreløpig, som den kjipe lillebroren til ZFS.

 

EDIT: og jfs, xfs, ext3 er besteforeldre som snakker om hvor enkelt alt var før.

Endret 2. februar 2011 av kpolberg

[Del]

Det er ZFS som er kjipt, du har jo snudd det på huet.

[Sokkalf™]

Hva er kjipt med ZFS, hvis man utelukker alt ikke-teknisk?

[Lycantrophe]

Lisensen? BSD og ikke GPL? (som gjør at linuximplementasjon ikke går, no?)

 

Err, det var jo det ikke-tekniske. ZFS og btrfs virker begge fint for min del, gleder meg til btrfs kommer enda lengre.

Endret 2. februar 2011 av Lycantrophe

[Del]

Rett fra en av ZFS utviklerne:

In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS. One of the major problems with the ZFS approach - "slabs" of blocks of a particular size - is fragmentation. Each object can contain blocks of only one size, and each slab can only contain blocks of one size. You can easily end up with, for example, a file of 64K blocks that needs to grow one more block, but no 64K blocks are available, even if the file system is full off nearly empty slabs of 512 byte blocks, 4K blocks, 128K blocks, etc. To solve this problem, we (the ZFS developers) invented ways to create big blocks out of little blocks ("gang blocks") and other unpleasant workarounds. In our defense, at the time btrees and extents seemed fundamentally incompatible with copy-on-write, and the virtual memory metaphor served us well in many other respects.

 

In contrast, the items-in-a-btree approach is extremely space efficient and flexible. Defragmentation is an ongoing process - repacking the items efficiently is part of the normal code path preparing extents to be written to disk. Doing checksums, reference counting, and other assorted metadata busy-work on a per-extent basis reduces overhead and makes new features (such as fast reverse mapping from an extent to everything that references it) possible.

ref. http://lwn.net/Articles/342892/

 

Btrfs rules

[Sokkalf™]

Uansett, "unpleasant workarounds" har vist seg å være både effektivt, raskt og stabilt.

 

For all del, det er fantastisk at vi nå får et helt fritt filsystem av samme (eller bedre) kaliber - men det må være lov å vente til det er litt mer "tried and tested".

[noob11]

en liten ting i forhold til jbod. Er det ikke tryggere å bruke aufs eller tilsvarende istedenfor? Det har vel samme fordeler men man slipper å miste alt om en disk ryker.