Gå til innhold

Den frie kafeen


Anbefalte innlegg

Jeg forstår ikke hvordan dere får til flere dager på rekonstruksjon av en 3TB disk i ett RAID5 sett. Jeg byttet en disk for ikke alt for lenge siden i mitt RAID5 sett á 4x 3TB disker(mdadm). Og det tok rett i overkant av 10 timer

Du brukte mdadm, forsøk det samme med zfs ;)
Lenke til kommentar
Videoannonse
Annonse
Hva er egentlig et praktisk bruksområde for krymping, JohnDoe?
Filserveren min har i dag 13 spinnedisker og én SSD på noe sånn som 2, 2, 1.5, 1.5, 1.5, 1.5, 1, 1, 1, 1, 1, 1, 0.75 og 0.04 TB, totalt omtrent 17TB. Dette er gjort ved å kjøpe to og to like disker over flere år som på det tidspunktet har optimal pris/lagring. Men selv om 0.75 TB ikke er direkte lite er det ikke lenge til både den og 1 TB-diskene bør byttes ut med et mindre antall større disker, f.eks til 8 disker totalt. Men etter at alle 1TB-diskene er byttet ut vil igjen det beste rent økonomisk være å legge til disker uten å fjerne noen, og slik vil behovet for mange og få disker gå opp og ned etter om en generasjon disker er så gamle at de bør fjernes.

 

I dag er alle diskene selvstendige og jeg har et oppstartsscript som symlinker alt innhold sammen slik at innholdet leses fra én enhet selv om lagringen blir gjort spredt. Det optimale hadde selvsagt vært om dette var gjort av filsystemet og at jeg kunne hatt redudans på dataene, men siden jeg har forskjellig størrelse på enhetene trenger jeg noe som RAIDZ og siden jeg ønsker å shrinke og growe har jeg ventet og ventet.

Endret av JohndoeMAKT
Lenke til kommentar

Du har jo fortsatt ikke nevnt noe brukjsområde for krymping - snarere tvert imot. :p

 

Med mindre du kjører helt uten redundans selvfølgelig, og tilsvarende ville vært rais0 -da kan ikke ZFS hjelpe deg. Men du kunne fint lagt til to og to disker til poolen som et raid1 vdev. Når diskene skal byttes ut, bytter du først den ene, lar den resilvre, og bytter så ut den andre. Vips, så har du kapasitet tilsvarende de nye, større diskene. (Eller halvparten, da, mtp raid1)

 

Men enterprise-fokuset gjør nok at man ike har tenkt så mye på de som skal oppgradere fra 400GB-disker til 3TB-disker i raid0 uten ha noe sted å lagre dataene i mellomtiden, eller en backup å kopiere tilbake fra.

 

Det høres ut som det du trenger er unraid.

 

red: Mente selvfølgelig greyhole, vi snakker da FLOSS, selvfølgelig.

 

Jeg har faktisk bra lyst til å prøve det selv, men det virker liksom ikke... helt trygt. :p Eller effektivt. Men jeg ville sluppet å bruke 150% av plassen diverse mediafiler tar som jeg enten kan rippe eller laste ned på nytt for å få redundans på de filene jeg ønsker det på.

Endret av NgZ
Lenke til kommentar

Fikk ikke med meg at du ønsket å fjerne syv og leggetil to, tenkte du byttet ut de minste etter hvert som du trengte mer plass. Mulig jeg leste dårlig. Det finnes en del triks tilgjengelige som å lage midlertidige pooler på fiktive blockdevices, men det krever jo en *smule* nerve - og tid. Og plass.

 

Angående redundans har du rett - de liker ikke å miste musikksamlingen sin eller bildene sine. Så om man tilfeldigvis har en samboer i huset, er en tredjedel av diskplassen en billig investering. ;)

Lenke til kommentar

Ikke behov for krymping? Jeg har tretten disker og ønsker å fjerne syv og legge til to, må jeg ikke shrinke poolet da?

Tror faktisk ikke det når det gjelder btrfs. For ditt bruk er btrfs modent nå, du vil bare bruke raid0, såvidt jeg har forstått kan du da fjerne disker nærmest uten videre:

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Removing_devices

Du kan også legge til nye disker like enkelt, bare husk å kjøre en balance etterpå for å få fordelt dataene til de nye diskene.

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Adding_new_devices

Angående redundans har du rett - de liker ikke å miste musikksamlingen sin eller bildene sine. Så om man tilfeldigvis har en samboer i huset, er en tredjedel av diskplassen en billig investering. ;)

Redundans og back-up er to forskjellige ting. Redundans beskytter ikke musikksamlingen mot ufrivillig sletting, men det gjør tilgjengeligheten av den sikrere.
Lenke til kommentar

Nå skal det noe til å slette musikksamlingen ufrivillig, og i tilfelle har man da selvfølgelig et ZFS snapshot. ;)

 

Men jeg gleder meg til btrfs er klart for mitt bruk, er kjekt å kjøre en helt integrert linuxløsning, selv om zfsonlinux ser ut til å gjøre det veldig bra.

 

Så fort jeg kommermeg over på linux skal jeg også sette opp Crashplan, sånn apropo backup.

Endret av NgZ
Lenke til kommentar

Snapshot er ikke ideelt som back-up. Du må da selv finne ut hvilke filer som er lagt til etter forrige snapshot, og legge disse tilbake igjen i snapshot. Det fordrer jo også at du vet når filene ble slettet, slik at du finner riktig snapshot. Det skal svært lite til for at noen sletter feil fil, eller på annen måte roter til filsystemet. Jeg har gjort det selv.

Lenke til kommentar

Hva mener du?

At kryptering typisk brukes på laptoper som er vanskelig å sikre fysisk. En filserver har man sjelden stående på utsatte steder, en låst dør og godt nettverk er normalt god nok sikring.
Jo, nå som det ikke er kryssavhengighet mellom enhetene trenger jeg ikke redundans. Med btrfs blir det kryssavhengighet og da trenger jeg det.

Såvidt jeg har forstått er det ikke kryssavhengighet med btrfs (i den forstand at hvis en disk ryker, må alt inn på nytt), Du kan velge om metadata skal være redundant, standard er at metadata er redundant med mindre du eksplisitt velger at den skal stripe metadata.
Lenke til kommentar

Man kan ikke tilfeldigvis velge å ha redundans på enkelte mapper og? For da holder raid0 lenge for meg. DET hadde vært en killer-feature. Btrfs harjo generelt en dårligere håndtering av mounts, så jeg ville blitt overrasket om de hadde DET, men.

 

God bedring med foten, forresten. Må ikke sjangle rundt i fylla på isen! :p

Endret av NgZ
Lenke til kommentar

Man kan ikke tilfeldigvis velge å ha redundans på enkelte mapper og? For da holder raid0 lenge for meg. DET hadde vært en killer-feature. Btrfs harjo generelt en dårligere håndtering av mounts, så jeg ville blitt overrasket om de hadde DET, men.

Det kalles back-up, ha kopi av disse mappene på en egen disk, det er en enkelt og godt fungerende løsning. Settes enkelt opp i et vell av alternative gui's for cron+rsync evt rdiff-backup.
God bedring med foten, forresten. Må ikke sjangle rundt i fylla på isen! :p

Takker. Heh, slalåmbakken, ikke isen. Vridning, delvis avrevet korsbånd og leddbånd, begge bena i leggen brukket :confused: kort sesong i år med andre ord. Mitt råd, forsiktig hvis du kjører med damen i bakken. Kvinner er uforutsigbare. Lindesy Vonn fikk helikopter, men skipatruljen på Oppdal stilte med snøscooter og topp service :thumbup:
Lenke til kommentar

Jada, backup er en ting, men tenk så flott å kunne ha redundans kun på utvalgte filer/mapper! :) Har egentlig ikke lyst å kaste bort redundans på filmsamlingen, men gidder ikke være uten på andre ting, selv etter at backup er i boks.

 

red: Om jeg går for CrashPlan unlimited, kan jeg jo kjøre alt opp dit og drite i redundans i det hele tatt, med 70Mbit ned.

Endret av NgZ
Lenke til kommentar
Psh, kjør på med greyhole.
Jeg tror egentlig at dagens løsning holder frem til btrfs dekker alle behov og gjør det bedre. Mitt script i dag gjør omtrent dette:

truecrypt --auto-mount=favorites
ln -s /media/truecrypt*/* /var/www/share
ln -s /media/truecrypt12 /media/active

Den som er "active" har ledig plass og jeg rsyncer data inn der fra bruksmaskinen til den er full, da blir neste tomme valgt som "active". Enkel hack, men det har fungert i fire år problemfritt.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...