Newsgroup: it.comp.os.linux.iniziare
Titolo: problema bzip2 grandi

Quando vado a costruire (con tar -cjf) un bzip2 di certe dimensioni,
spesso e volentieri il file risulta corrotto.
Le dimensioni si aggirano intorno al gigabyte
bzip2: Data integrity error when decompressing.
        Input file = (stdin), output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
Nessun problema con quelli più piccoli.
Credo che passerò ai tar.gz, però non vedo la cosa molto normale. Si
tratta di backup di intere partizioni.
Matteo

 Credo che passerò ai tar.gz, però non vedo la cosa molto normale.
Testata la ram?
-- 
Best Regards, Jack
Linux User #264449
Powered by Fedora Core 6 & Xubuntu (x86)
Powered by Debian Sid (ppc & AMD64)


si, anche se non vedo cosa possa entrarci... se la ram è guasta la
macchina crasha oppure mi corrompe anche quelli piccoli... insomma si
ripercuoterebbe anche su altro.
Comunque adesso ho settato per il gzip e vediamo come va. Per fortuna
faccio anche i backup incrementali oltre ai full.
Matteo

 
Escluso problemi banali (p.e. il filesystem non suppota 
file oltre i 2 GiBi), io controllerei la memoria RAM ed 
i dischi in cerca di settori danneggiati (non escludendo 
la partizione di swap).

 la partizione di swap).
Non appena posso reboottare controllo (in effetti non avevo mai
controllato la swap).
Ah, i dischi sono in raid hardware.
Matteo

mmm, non ho ancora provato a gzippare, ma mi sa tanto che si tratta
della ram e/o swap, o bug del kernerl (2.6.5-7.97-smp). Come prima
prova (che non richiede reboot) proverò a disattivare la swap. Ho 2
giga di ram, dovrebbe bastarmi.
Matteo
# dmesg
Code: 8b 10 85 d2 74 1f b8 00 e0 ff ff 21 e0 83 3a 02 8b 40 10 0f
 <1>Unable to handle kernel paging request at virtual address ba887e60
 printing eip:
c0166e3f
*pde = 00000000
Oops: 0000 [#20]
SMP
CPU:    0
EIP:    0060:[<c0166e3f>]    Not tainted
EFLAGS: 00010286   (2.6.5-7.97-smp)
EIP is at dentry_open_it+0x7f/0x220
eax: ba887e60   ebx: f4d37480   ecx: 00000001   edx: c73e5f44
esi: cc3ff51c   edi: f7fe1780   ebp: f40a7410   esp: c73e5f08
ds: 007b   es: 007b   ss: 0068
Process tar (pid: 13410, threadinfo=c73e4000 task=dc3cc870)
Stack: ffffffe9 00008000 c73e5f44 c73e5f70 00000000 c01670d9 c73e5f44
f736c000
       f40a7410 f7fe1780 00000000 000000e7 00000000 00000101 00000001
19620323
       00000001 00000000 00008001 00000000 00000000 00000000 00000000
00000000
Call Trace:
 [<c01670d9>] filp_open+0x89/0xa0
 [<c016717d>] sys_open+0x8d/0xf0
 [<c01091e9>] sysenter_past_esp+0x52/0x79
Code: 8b 10 85 d2 74 1f b8 00 e0 ff ff 21 e0 83 3a 02 8b 40 10 0f

 ripercuoterebbe anche su altro.
Se la RAM è bacata il comportamento è imprevedibile. Probabilmente ti
succede solo con quelli grandi perchè fanno lavorare di più la RAM e va a
toccare la zona sminchia.
-- 
Vide
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


Vero, era un banco di ram, da 512Mb :-(
Per fortuna avevo 2Gb di ram su quella macchina.
Quello che non mi spiego è come mai il banco lo beccasse solamente in
quei casi, visto che si tratta del primo; per la precisione l'errore
era al 195° Mb, che non è molto alto e che dovrebbe essere abbastanza
facilmente beccabile da altri programmi.
A questo punto la domanda sorge spontanea:
se, ad eccezione di grandi bzip, non mi viene beccato nemmeno il bit al
195°Mb, quale sarà la probabilità che il mio server arrivi ad
utilizzare l'ultimo banco di memoria ?
Matteo