Disksjekk
Steinar Midtskogen
maskiner som sjelden bootes mer enn en gang i �ret med noen terabyte
disk. Default er vel at disken sjekkes dersom det har g�tt over 180
dager sia forrige sjekk, som vil bety at det tar timer � boote en slik
boks, noe som i mange tilfelle vil v�re uakseptabelt. F�r i tida da
diskene ikke var s� store, var ikke dette noe stort problem.
Er det vanlig praksis � skru av alt slikt med tune2fs, trengs egentlig
slike sjekker med ext3?
--
Steinar ; NIL DIFFICILE VOLENTI ; http://latinitas.org ; http://voksenlia.net
Dag-Erling Smørgrav
> Hva er vanlig praksis for disksjekk på Linux-tjenere for tida? For
> maskiner som sjelden bootes mer enn en gang i året med noen terabyte
> disk. Default er vel at disken sjekkes dersom det har gått over 180
> dager sia forrige sjekk, som vil bety at det tar timer å boote en slik
> boks, noe som i mange tilfelle vil være uakseptabelt. Før i tida da
> diskene ikke var så store, var ikke dette noe stort problem.
Det er derfor man har andre filsystemer i dag enn man hadde den gang.
Hvis maskinen er en ren filtjener kan du f.eks. vurdere å bytte til
FreeBSD, og kjøre ZFS.
DES
--
Dag-Erling Smørgrav - d...@des.no
Steinar Midtskogen
> Steinar Midtskogen <ste...@latinitas.org> writes:
>> Hva er vanlig praksis for disksjekk p� Linux-tjenere for tida? For
>> maskiner som sjelden bootes mer enn en gang i �ret med noen terabyte
>> disk. Default er vel at disken sjekkes dersom det har g�tt over 180
>> dager sia forrige sjekk, som vil bety at det tar timer � boote en slik
>> boks, noe som i mange tilfelle vil v�re uakseptabelt. F�r i tida da
>> diskene ikke var s� store, var ikke dette noe stort problem.
>
> Det er derfor man har andre filsystemer i dag enn man hadde den gang.
> Hvis maskinen er en ren filtjener kan du f.eks. vurdere � bytte til
> FreeBSD, og kj�re ZFS.
Hvilket filsystem under Linux regnes for tida som "best". Jeg brukte
en periode reiserfs, men gikk etter et par �r tilbake til ext3 uten at
jeg helt husker hvorfor.
Maskinen er mye mer enn filtjener og jeg sikter mot � holde
vedlikeholdsarbeidet (inkludert reinstalleringer) nede p� noen timer i
�ret, s� da blir det ikke aktuelt � skifte os.
Steinar Midtskogen
> [Dag-Erling Sm�rgrav]
>
>> Steinar Midtskogen <ste...@latinitas.org> writes:
>>> Hva er vanlig praksis for disksjekk p� Linux-tjenere for tida? For
>>> maskiner som sjelden bootes mer enn en gang i �ret med noen terabyte
>>> disk. Default er vel at disken sjekkes dersom det har g�tt over 180
>>> dager sia forrige sjekk, som vil bety at det tar timer � boote en slik
>>> boks, noe som i mange tilfelle vil v�re uakseptabelt. F�r i tida da
>>> diskene ikke var s� store, var ikke dette noe stort problem.
>>
>> Det er derfor man har andre filsystemer i dag enn man hadde den gang.
>> Hvis maskinen er en ren filtjener kan du f.eks. vurdere � bytte til
>> FreeBSD, og kj�re ZFS.
>
> Hvilket filsystem under Linux regnes for tida som "best". Jeg brukte
> en periode reiserfs, men gikk etter et par �r tilbake til ext3 uten at
> jeg helt husker hvorfor.
For � supplere litt: Det er snakk om 2-3 TB diskplass i raid1 med 4-5
millioner filer og lett bruk.
Karl Ove Hufthammer
> Er det vanlig praksis å skru av alt slikt med tune2fs, trengs egentlig
> slike sjekker med ext3?
Det kan eg ikkje uttala meg om, men kan iallfall opplysa om at sjekkane går
veldig mykje raskare med ext4:
http://kernelnewbies.org/Ext4#head-9a25213c5b924bdb8b33efbcb91bfa1279bd2b00
(Men dei går jo raskare med ein del andre filsystem òg, so …)
--
Karl Ove Hufthammer
E-post/Jabber: ka...@huftis.org
David Brown
> Hva er vanlig praksis for disksjekk p� Linux-tjenere for tida? For
> maskiner som sjelden bootes mer enn en gang i �ret med noen terabyte
> disk. Default er vel at disken sjekkes dersom det har g�tt over 180
> dager sia forrige sjekk, som vil bety at det tar timer � boote en slik
> boks, noe som i mange tilfelle vil v�re uakseptabelt. F�r i tida da
> diskene ikke var s� store, var ikke dette noe stort problem.
>
> Er det vanlig praksis � skru av alt slikt med tune2fs, trengs egentlig
> slike sjekker med ext3?
>
Teoretisk, nei, du trenger ikke sjekker. Hvis du ikke har hatt
problemer med serveren eller uventet str�mstans, er det sv�rt lite sjans
at det har kommet feil i filsystemet. 180 dager regelen er bare en
ekstra sjekk for � begrense omfanget av skaden dersom noe har g�tt galt,
eller hvis det er en bugs i filsystemkoden.
En fin triks (som er kanskje for sent for deg n�...) er � bruke LVM2 til
partisjonene, og ta en snapshot av filsystemet inn i blant. Man kan da
kj�re en fsck p� snapshot'en uten at det p�virker selve data partisjonen
eller f�rer til downtime. Dersom fsck p� snapshot er ok, s� er data
partisjonen, og du kan slette snapshoten. Dersom fsck p� snapshot
feiler, s� trenger du � ta en virkelig fsck p� data partisjonen. Du kan
t.o.m. �ve p� snapshot'en for � se at fsck'en klarer � fikse opp i
problemene.
David Brown
Det fins ingen "best", bare mange valg :-)
Reiserfs var en god valg f�r i tiden, er spesielt effektivt til mange
sm� filer, og det g�r ekstremt raskt � lage nye reiserfs filsystemer,
eller � �ke st�rrelse p� dem (p� LVM2 partisjoner). Men det er lite
framtidsrettet (du finer historien om Hans Reiser p� nettet), og flere
mener det er ikke s�rlig p�litelig.
XFS er gode til st�rre filer, og til � jobbe med mange klienter
samtidig. Men det er kjent for � v�re litt farlig ved uventet stopp
(bruk en UPS!), og en full fsck bruker mye minne - jo st�rre disken er,
jo mer minne.
ext3 regnes som standard Linux filsystem, og er fint for de alle fleste
bruksomr�der. Det er ikke p� toppen av alle benchmarker, men heller
ikke spesielt d�rlig p� noen av dem.
ext4 er den nye ext'en, og har en rekke forbedring over ext3. Spesielt
extents gj�r det mer effektivt p� st�rre filer, og det er mye raskere i
fsck enn ext2/3. Men du trenger en noks� ny kernel. Det har v�rt mye
snakk p� nettet om faren for � miste data ved crash p� ext4 - det er den
samme som med xfs (eller ext3 i "writeback" modus). Metadata kan v�re
skrevet ut p� disken f�r selve data'en, og en uheldig crash kan f�re til
en fil av 0 lengde. Dette kan ogs� skje med ext3 i "ordered" mode, men
sjansene er mye mindre (fordi det er kortere tid mellom skrivingene).
De siste kernel patcher p� ext4 lukke dette vinduet for mange type
skriveoperasjoner. Men p� en server med UPS og stabilt programvare, er
dette ikke et problem - og "writeback" caching som ext3 (writeback),
ext4, og xfs bruker �ker throughput.
btrfs er sett p� som framtidens filsystem til Linux - det er p� vei til
� kunne gj�re alt som ZFS kan, og litt til. Men det er ikke stabilt
enn�, og heller ikke komplett i planlagde funksjoner. Det er et
ubesvart sp�rsm�l hvordan framtiden blir n� som Oracle (som har laget
btrfs) har kj�pt Sun (som lager ZFS). Det kan bety at ZFS blir
tilgjengelig for Linux (det fins i dag som FUSE filsystem, men ikke i
kernel), og det kan bety at Oracle n� f�r flere erfarende filsystem
utviklere som kan hjelpe til med btrfs.
I oppsummering, er ext3 vanligvis det rette valg dersom man trenger en
moden og godt utpr�vd filsystem. Dersom man kan ta litt st�rre risiko
for � f� �kt funksjonalitet og �kt hastighet men det beste av de kurante
filsystemer, er ext4 et godt valg med en nyere kernel.
mvh.,
David
Jan-Frode Myklebust
>
> En fin triks (som er kanskje for sent for deg n�...) er � bruke LVM2 til
> partisjonene, og ta en snapshot av filsystemet inn i blant.
"Poor man's background scrubbing"-oppskrift:
http://permalink.gmane.org/gmane.linux.kernel/622137
-jf
Jan-Frode Myklebust
> problemer med serveren eller uventet str�mstans, er det sv�rt lite sjans
> at det har kommet feil i filsystemet. 180 dager regelen er bare en
> ekstra sjekk for � begrense omfanget av skaden dersom noe har g�tt galt,
> eller hvis det er en bugs i filsystemkoden.
Eller bugs i minne, kabler, firmware, raid-kontrollere, SAN, etc..
Det er mye som kan feile, og det er kjekt � oppdage slike feil s� tidlig
som mulig, for � begrense skadene. Jeg ble nettopp bitt av en firmware-bug
p� SAN som korrumperte ett 30TB filsystem, og ikke var synlig f�r vi
avmonterte/remonterte dette filsystemet. Ingen feil var synlige f�r
filsystemet traverserte inodestrukturen ved montering, og ville naturlig
nok ikke monteres lengre n�r den oppdaget at den fikk korrupte data fra
disk.
Neste gang noe slik skjer, h�per jeg � ha p� plass diverse online
sanity-checks som kan oppdage dette tidlig.
-jf
Steinar Midtskogen
Jeg bruker ikke LVM, men kan en metode ettersom jeg kj�rer raid1 � ta
fjerne den ene disken fra raidet, kj�re fsck p� denne, legge den
tilbake og kj�re samme prosedyre p� den andre disken? Mulig at den
offline disken ikke er i helt god stand logisk ved � ta den ut slik
(kanskje det hjelper � remounte ro f�r den fjernes?), men jeg burde
kunne f� sjekka for mer fysiske problem.
Bjørn Mork
> On 2009-05-08, David Brown <david...@hesbynett.removethisbit.no> wrote:
>>
>
> "Poor man's background scrubbing"-oppskrift:
>
> http://permalink.gmane.org/gmane.linux.kernel/622137
Kjempetips! Takk.
Bjørn
--
I firmly believe that the Martians are coming
Bjørn Mork
> Jan-Frode Myklebust <myk...@no.ibm.com> writes:
>> On 2009-05-08, David Brown <david...@hesbynett.removethisbit.no> wrote:
>>>
>>> En fin triks (som er kanskje for sent for deg nå...) er å bruke LVM2 til
>>> partisjonene, og ta en snapshot av filsystemet inn i blant.
>>
>> "Poor man's background scrubbing"-oppskrift:
>>
>> http://permalink.gmane.org/gmane.linux.kernel/622137
>
> Kjempetips! Takk.
Men jeg måtte gjøre noen småjusteringer for å få dette til å kjøre på
min Debian stable installasjon:
"nice +20" => "nice -n 20"
pussig egentlig, men jeg gidder ikke finne ut hvorfor jeg ikke har en
nice som aksepterer +20
"lvcreate ..." => "lvcreate --size 50G ..."
insisterte på å få angitt en størrelse for snapshotet. 50G er nok
for mye, men ihvertfall stort nok for alle mine filsystemer. Og jeg
har plass til det
"tune2fs -C 16383 -T "19000101" " => "tune2fs -C 255 -T "20000101" "
tune2fs nektet å akseptere 16383 mounts, og 255 er jo mer enn nok
(aner ikke hva som er reell maks)
19000101 ble akseptert som input:
"Setting time filesystem last checked to Mon Jan 1 00:00:00 1900"
men endte opp som noe helt annet:
"Last checked: Thu Feb 7 06:28:16 2036
Check interval: 15552000 (6 months)
Next check after: Tue Aug 5 07:28:16 2036"
Siden vi har passert år 2000 med god margin, og jeg uansett bare har 6
måneders intervall, så holder det lenge med 20000101 for meg.
lvremove "${VG}/${VOLUME}-snap" => lvremove -f "${VG}/${VOLUME}-snap"
Ellers vil jo lvremove gjerne ha en bekreftelse på at du virkelig
vil...
Device-navnene stemte heller ikke. Navnene i /dev/mapper har bindestrek
mellom VG og LV, ikke underscore. Og (antageligvis derfor) snapshotet
fikk en ekstra bindestrek, slik at fullt navn ble noe ala
"/dev/mapper/vg00-root--snap"
Bruker derfor heller symlinkene /dev/<vg>/<lv> i stedet. F.eks.
"/dev/vg00/root-snap"
I tillegg synes jeg der er rimelig å teste på om lvcreate er vellykket
før man kjører videre. Eksempel på feil du *ikke* vil scriptet skal
ignorere: Det kan finnes en "${VOLUME}-snap" fra før...
Resultatet ble noe slikt:
START="$(date +'%Y%m%d%H%M%S')"
if ! lvcreate --size 50G --snapshot --name "${VOLUME}-snap" "${VG}/${VOLUME}"; then
echo "Failed to create snapshop"
exit 1
fi
if nice -n 20 fsck -fy "/dev/${VG}/${VOLUME}-snap"; then
echo 'Background scrubbing succeeded!'
tune2fs -T "${START}" "/dev/${VG}/${VOLUME}"
else
echo 'Background scrubbing failed! Reboot to fsck soon!'
tune2fs -C 255 -T "20000101" "/dev/${VG}/${VOLUME}"
fi
lvremove -f "${VG}/${VOLUME}-snap"
Er nå kjørt på root (50G) og home (500G) med resultatet at root trenger
en fsck. Sist den ble sjekket var i desember 2008. Men siden da har
jeg bla erstattet en død disk og hatt en strømbrudd-reboot, så
potensialet for feil var definitivt til stede.
Bjørn
--
No nukes
Bjørn Mork
> Jan-Frode Myklebust <myk...@no.ibm.com> writes:
>> On 2009-05-08, David Brown <david...@hesbynett.removethisbit.no> wrote:
>>>
>>> En fin triks (som er kanskje for sent for deg nå...) er å bruke LVM2 til
>>> partisjonene, og ta en snapshot av filsystemet inn i blant.
>>
>> "Poor man's background scrubbing"-oppskrift:
>>
>> http://permalink.gmane.org/gmane.linux.kernel/622137
>
> Kjempetips! Takk.
Eh, jeg tror jeg trekker den tilbake. Har begynt å få en viss idé om
hvorfor dette ikke er default oppførsel. Det virker forsåvidt under
visse forutsetninger, men mulighetene for at metoden forårsaker helt
unødvendig fsck er store.
Har du åpne filer som er slettet, så vil fsck alltid rette dette. F.eks:
Clearing orphaned inode nnnnn (uid=0, gid=0, mode=0100644, size=0)
Dette er helt uskyldig og relativt normalt. Dessverre får det fsck til
å returnere 1, og dermed trigger scriptet et full fsck ved neste
reboot. Helt unødvendig.
Ser ikke noen gode veier rundt dette uten å begynne å parse output fra
fsck. Og det blir for stygt for meg.
Bjørn
--
How can you say that you're young
David Brown
> [Jan-Frode Myklebust]
>
>> On 2009-05-08, David Brown <david...@hesbynett.removethisbit.no> wrote:
>>> En fin triks (som er kanskje for sent for deg n�...) er � bruke LVM2 til
>>> partisjonene, og ta en snapshot av filsystemet inn i blant.
>> "Poor man's background scrubbing"-oppskrift:
>>
>> http://permalink.gmane.org/gmane.linux.kernel/622137
>
> Jeg bruker ikke LVM, men kan en metode ettersom jeg kj�rer raid1 � ta
> fjerne den ene disken fra raidet, kj�re fsck p� denne, legge den
> tilbake og kj�re samme prosedyre p� den andre disken? Mulig at den
> offline disken ikke er i helt god stand logisk ved � ta den ut slik
> (kanskje det hjelper � remounte ro f�r den fjernes?), men jeg burde
> kunne f� sjekka for mer fysiske problem.
>
Jeg tror det skulle v�re mulig, men jeg er ikke sikker. Du trenger bare
� kj�re fsck p� denne ene disken - fsck er et logisk sjekk av
filsystemet, ikke en sjekk av disken selv.
Det er en del ting � tenke p� her. Jeg har ikke pr�vd noe lignende, s�
ikke klag hvis det ikke virker! (Men gi gjerne tilbakemelding, om det
virker eller ei.)
F�rst, ta en fullstendig backup.
Neste, dobbelsjekk at backup'en fungerte, og at det du kan f� filene
tilbake.
Bruk "mdadm --group --bitmap=internal /dev/mdX" slik at du har en bitmap
p� raid'en. Denne bitmapen holder orden p� hvor p� disken data blir
endret, slik at en rsync blir raskere. Bitmap'en gj�r vanlig write
operasjoner tregere, men det gj�re en rsync etter powerfeil raskere.
Tanken min er at det vil gj�re det fortere � f� rsync'en her til �
fungere fortere, men jeg vet ikke om det er sant i praksis.
Fjern den ene driven, og kj�re fsck p� den med "-N" flag (d.v.s., unng�
� endre noe - da har du ikke sjans � synce diskene igjen). Dersom det
er i orden, legge den inn igjen og fjern bitmap'en. Har jeg rett
ang�ende bitmapen, g�r dette fort siden bare endringene trengs � bli
kopierte. Tar jeg feil, m� du vente en stund gjennom rebuild.
Dersom fsck feiler, kan du enten koble driven inn igjen og kj�re en full
offline fsck p� hele filsystemet, eller jukse litt og kj�re fsck bare p�
den ene partisjonen mens den andre er fortsatt online. N�r fsck er
ferdig, stopper du raiden, umount, fjerne den d�rlige partisjonen, og
legge inn den gode. Da ta du filsystemet online igjen, legge inn den
d�rlige partisjonen, og lar en resync flytte endringene over til den
andre disken. Dette blir mer risikabelt, og du misser endringer som
blir lagret underveis, men har mindre downtime.
Dag-Erling Smørgrav
> Jeg bruker ikke LVM, men kan en metode ettersom jeg kjører raid1 å ta
> fjerne den ene disken fra raidet, kjøre fsck på denne, legge den
> tilbake og kjøre samme prosedyre på den andre disken?
I mellomtiden er arrayet gått i "degraded mode", og når du kobler inn
igjen den første disken setter LVM i gang med å kopiere alt over fra den
andre. Bytt til ZFS.
David Brown
Hvis man først skulle bytte OS for å kunne kjøre ZFS, hvorfor ikke
OpenSolaris?
Dag-Erling Smørgrav
> Dag-Erling Smørgrav <d...@des.no> writes:
> > Det er derfor man har andre filsystemer i dag enn man hadde den
> > gang. Hvis maskinen er en ren filtjener kan du f.eks. vurdere å
> > bytte til FreeBSD, og kjøre ZFS.
> OpenSolaris?
OpenSolaris har en glimrende kjerne, men mangler omtrent alt annet som
man forventer å finne i et moderne operativsystem.
David Brown
Hvis man først skulle bytte OS for å kunne kjøre ZFS, hvorfor ikke
OpenSolaris?
David Brown
Greit nok forklaring!
mvh.,
David
Carsten A. Arnholm
> I oppsummering, er ext3 vanligvis det rette valg dersom man trenger en
> moden og godt utpr�vd filsystem. Dersom man kan ta litt st�rre risiko
> for � f� �kt funksjonalitet og �kt hastighet men det beste av de kurante
> filsystemer, er ext4 et godt valg med en nyere kernel.
>
> mvh.,
> David
Takk for godt og instruktiv oppsummering av Linux filsystemer!
Mvh
Carsten Arnholm
Jan-Frode Myklebust
>
> Har du åpne filer som er slettet, så vil fsck alltid rette dette. F.eks:
>
> Clearing orphaned inode nnnnn (uid=0, gid=0, mode=0100644, size=0)
>
> Dette er helt uskyldig og relativt normalt. Dessverre får det fsck til
> å returnere 1, og dermed trigger scriptet et full fsck ved neste
> reboot. Helt unødvendig.
>
> Ser ikke noen gode veier rundt dette uten å begynne å parse output fra
> fsck. Og det blir for stygt for meg.
Her er en litt oppdatert løsning fra Ted Tso, ferdig cronjobb som
fikser fiksbare feil i snapshot'et slik at disse ikke gir alarm:
http://article.gmane.org/gmane.linux.documentation/706
-jf
Bjørn Mork
Ah, right. Den kjører "e2fsck -p" først og fjerner dermed ikke-kritiske
feil før det kjører "e2fsck -fy". Lurt. Takk for tipset
Prøvde det nettopp på et helt ekte root-filsystem med en del typiske
slike "feil" som oppstår ved normal bruk:
canardo:/home/bjorn# /tmp/x.sh
Logical volume "root-snap" created
/dev/vg00/root-snap: Clearing orphaned inode 1689738 (uid=0, gid=0, mode=0100644, size=2148304)
/dev/vg00/root-snap: Clearing orphaned inode 1687642 (uid=0, gid=0, mode=0100644, size=2138416)
/dev/vg00/root-snap: Clearing orphaned inode 3819563 (uid=104, gid=65534, mode=0100600, size=0)
/dev/vg00/root-snap: Clearing orphaned inode 3820585 (uid=104, gid=65534, mode=0100600, size=0)
/dev/vg00/root-snap: Clearing orphaned inode 3817831 (uid=104, gid=65534, mode=0100644, size=113490)
/dev/vg00/root-snap: Clearing orphaned inode 3821030 (uid=104, gid=65534, mode=0100600, size=0)
/dev/vg00/root-snap: Clearing orphaned inode 3819532 (uid=104, gid=65534, mode=0100644, size=2237)
/dev/vg00/root-snap: Clearing orphaned inode 999493 (uid=0, gid=0, mode=0100755, size=2138496)
/dev/vg00/root-snap: Clearing orphaned inode 5324899 (uid=0, gid=0, mode=0100755, size=398568)
/dev/vg00/root-snap: Clearing orphaned inode 3821064 (uid=0, gid=0, mode=0100644, size=28800)
/dev/vg00/root-snap: Clearing orphaned inode 3821467 (uid=0, gid=0, mode=0100644, size=1)
/dev/vg00/root-snap: Clearing orphaned inode 3915845 (uid=0, gid=0, mode=0100644, size=0)
/dev/vg00/root-snap: Clearing orphaned inode 3964934 (uid=117, gid=117, mode=0100600, size=66432)
/dev/vg00/root-snap: clean, 531866/6553600 files, 4093283/13107200 blocks
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 9304k/0k (8167k/1138k), time: 128.88/ 6.38/ 1.94
Pass 1: I/O read: 903MB, write: 0MB, rate: 7.01MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 12008k/0k (9199k/2810k), time: 36.93/ 0.66/ 0.86
Pass 2: I/O read: 242MB, write: 0MB, rate: 6.55MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 12008k/0k (9999k/2010k), time: 166.23/ 7.05/ 2.80
Pass 3A: Memory used: 12008k/0k (9999k/2010k), time: 0.00/ 0.00/ 0.00
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 12008k/0k (9199k/2810k), time: 0.00/ 0.00/ 0.00
Pass 3: I/O read: 1MB, write: 0MB, rate: 261.64MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 8376k/0k (3959k/4418k), time: 0.09/ 0.09/ 0.00
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: Memory used: 8376k/0k (3159k/5218k), time: 0.57/ 0.32/ 0.01
Pass 5: I/O read: 3MB, write: 0MB, rate: 5.27MB/s
531866 inodes used (8.12%)
35735 non-contiguous inodes (6.7%)
# of inodes with ind/dind/tind blocks: 19906/432/0
4093283 blocks used (31.23%)
0 bad blocks
1 large file
460907 regular files
50672 directories
878 character device files
4530 block device files
30 fifos
63172 links
14774 symbolic links (11849 fast symbolic links)
66 sockets
--------
595029 files
Memory used: 8376k/0k (3159k/5218k), time: 166.92/ 7.46/ 2.81
I/O read: 1148MB, write: 1MB, rate: 6.88MB/s
Background scrubbing succeeded!
tune2fs 1.41.3 (12-Oct-2008)
Setting current mount count to 0
Setting time filesystem last checked to Thu Sep 3 12:48:27 2009
Logical volume "root-snap" successfully removed
Så den versjonen funker.
Da står vi bare igjen med en liten skjønnhetsmessig detalj: Konsekvensen
av å gjøre dette er at LVM-historien din blir full av snapshots som er
opprettet og fjernet. Gjør kanskje ikke så mye, men kan være litt
forvirrende.
Samt den vanlige problemstillingen ifm snapshots: Mens dette pågår har
du to filsystemer med samme UUID. Det kan medføre en smule trøbbel om
du booter midt i prosessen og du bruker UUID i /etc/fstab. Men det gjør
du forhåpentligvis ikke når du bruker LVM...
Men det er jo en løsning for de som ønsker litt mer forutsigbar nedetid
ifm reboot.
Bjørn
--
You're a typical Moonie person, totally bad