Date: Tue, 14 Nov 2006 17:39:38 +0100 From: Søren Klintrup <none@soren--klintrup.dk.lh.bsd-dk.dk> To: bsd-dk@bsd-dk.dk Subject: Re: BSD Trivia spørgsmål of the week - #1
Phil Regnauld wrote:
> "På en UFS partition løber man tør for inodes. Der er ikke plads nok på
> de andre partitioner for at flytte data og lave en symbolic link, og man
> kan ikke tilføje flere diske til maskinen. (Den sidder typisk i et rack,
> med remote adgang only). Hvilket workaround vil man kunne anvende for at
> løse problemet ?"
Nu er der ikke så meget information at man ligefrem vælter sig i det, så
jeg laver et par antagelser:
* Det er ikke et mountpoint som selve *BSD ligger på, ikke svært at
arbejde udenom dog.
* Oprydning ér forsøgt, og er ikke nok, simpel arkivering er ikke nok,
da data skal være online.
* En datamængde på ca 20 GB, det er vist en meget normal datamængde at
have på en almindelig rackmonteret server.
Min erfaring med netbsd og openbsd er begrændset, så det her baserer sig
primært på FreeBSD 6.1, det er standard unix utils jeg bruger, men
defaults og parametre kan være anderledes på andre BSD versioner.
Min umiddelbare løsning ville være at lave et dump af disken til en
anden storage-enhed, muligheder herfor inkluderer:
* USB Harddisk, nem og billig løsning - kræver fysisk adgang.
* En båndstation, SCSI, USB ,whatever man nu kan få fat i - kræver
fysisk adgang
* En anden partition, med en pipe gennem bzip -9 kan det være der er plads ?
* En anden maskine, evt i samme datacenter som har plads til datamængden ?
* For små datamængder kan en USB Flash key også bruges (1-2 GB) eller
lignende, men det ser jeg ikke som særlig sandsynligt :)
Herefter vil jeg lave en newfs på den føromtalte slice, og lave en
restore af data til denne - vupti.
Kommandoer der er rare at bruge, med et par rare options:
*newfs*
http://www.freebsd.org/cgi/man.cgi?query=newfs&sektion=8&apropos=0&manpath=FreeBSD+6.1-RELEASE
-i er tætheden på inodes, default på FreeBSD er 8192 - hvis den sættes
til f.eks. 4096 vil der være flere inodes til rådighed.
-b er blockstørrelsen, det er den mængde data der bliver allokeret af
gangen (undtagen den sidste block), default er 16384
-f er fragmentstørrelsen, det er det mindste allokerbare fragment på et
filsystem, den sidste block i en fil kan også være en fragment.
-U enable soft updates, skriver metadata asynkront god, sikker,
performanceboost
*dump*
http://www.freebsd.org/cgi/man.cgi?query=dump&sektion=8&apropos=0&manpath=FreeBSD+6.1-RELEASE
-0 giver fuldt dump
-b skifter blocksize, er især interresant til tape da det kan give et
godt performanceboost, dette skal også specificeres ved en restore,
størrelsen er i KB, så hvis der skrives 64 menes 64 KB, default er 10.
-a dump finder selv ud af længden på bånd/disk, en god idé at bruge.
-L laver et snapshot af filsystemet før den dumper, kan tage lang tid
hvis der er mange små filer, og hvis alle services der tilgår
filsystemet er stoppet er det forhåbentlig ikke nødvendigt (med mindre
noget er misset ;).
-f device/fil der skal tages backup til,
*restore*
http://www.freebsd.org/cgi/man.cgi?query=restore&sektion=8&apropos=0&manpath=FreeBSD+6.1-RELEASE
-r restore et helt filsystem
-f device/fil der skal restores fra
Eksempler:
*dump til disk*
dump -0aL -f - /home|bzip2 -9 >/usr/homebackup.dmp
newfs -i 4096 /dev/something
cd /home
bunzip2 /usr/homebackup.dmp|restore -rf -
*dump til tape*
dump -0aL -b 128 -f /dev/sa0 /home
newfs -i 4096 /dev/something
cd /home
restore -r -b 128 -f /dev/sa0
Det kan herudover skrives til et NFS mount på en anden maskine man har
det, man kan pipe det yderligere gennem ssh forholdsvis let (se eksempel
med dump til disk, og indsæt selv ssh i pipes, evt uden bzip, da det
godt kan tage meget lang tid at pakke data med bzip.
Hvis mine antagelser viser sig at være ude af trit med hvad du mente, må
du endelig komme med noget mere information ;)
Håber min mail giver mening, det er sent og jeg er på vej ud af døren.
/Søren
This archive was generated by hypermail 2b30 : Thu 30 Nov 2006 - 23:00:03 CET