Del Skrevet 6. februar 2013 Del Skrevet 6. februar 2013 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
JohndoeMAKT Skrevet 6. februar 2013 Del Skrevet 6. februar 2013 (endret) 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 6. februar 2013 av JohndoeMAKT Lenke til kommentar
NgZ Skrevet 6. februar 2013 Del Skrevet 6. februar 2013 (endret) Du har jo fortsatt ikke nevnt noe brukjsområde for krymping - snarere tvert imot. 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. 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 6. februar 2013 av NgZ Lenke til kommentar
JohndoeMAKT Skrevet 6. februar 2013 Del Skrevet 6. februar 2013 (endret) Ikke behov for krymping? Jeg har tretten disker og ønsker å fjerne syv og legge til to, må jeg ikke shrinke poolet da? EDIT: Redudans er for jenter. Endret 6. februar 2013 av JohndoeMAKT Lenke til kommentar
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 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
Del Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 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
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 (endret) 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 7. februar 2013 av NgZ Lenke til kommentar
Del Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 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
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 SNapshot er da like ideelt som backup, du kan kopiere tilbake feil filer der og. Men det ER jo ikke backup, det bør man ha i tillegg uansett. Lenke til kommentar
JohndoeMAKT Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 Jeg kan ikke bruke btrfs før RAID5 er stabilt nok. Og som nevnt i begynnelsen av denne samtalen må jeg legge til kryptering manuelt. Lenke til kommentar
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 Var det ikke du som ikke skulle ha redundans? Lenke til kommentar
Del Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 Kryptering på en så fet filserver, skulle tro det var bedre måter å sikre den på. Lenke til kommentar
JohndoeMAKT Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 <p> Kryptering på en så fet filserver, skulle tro det var bedre måter å sikre den på.Hva mener du? <p> Var det ikke du som ikke skulle ha redundans? Jo, nå som det ikke er kryssavhengighet mellom enhetene trenger jeg ikke redundans. Med btrfs blir det kryssavhengighet og da trenger jeg det. Lenke til kommentar
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 Psh, kjør på med greyhole. FREEBSD har jo en veldig god løsning med GEOM og GELI, i linux blir det vel en blockdevice oppå en annen uten helt den store samhandlingen. (Hvis du f.eks. går for luks) Lenke til kommentar
Del Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 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
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 (endret) 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! Endret 7. februar 2013 av NgZ Lenke til kommentar
Del Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 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! Takker. Heh, slalåmbakken, ikke isen. Vridning, delvis avrevet korsbånd og leddbånd, begge bena i leggen brukket 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 Lenke til kommentar
NgZ Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 (endret) 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 7. februar 2013 av NgZ Lenke til kommentar
cmyrland Skrevet 7. februar 2013 Del Skrevet 7. februar 2013 *snip* Takker. Heh, slalåmbakken, ikke isen. *snap* Må ihvertfall ikke sjangle rundt i fylla i slalåmbakken God bedring! Lenke til kommentar
JohndoeMAKT Skrevet 8. februar 2013 Del Skrevet 8. februar 2013 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
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå