| View previous topic :: View next topic |
| Author |
Message |
comio
Advocate
Joined: 03 Jul 2003
Posts: 2191
Location: Taranto
|
 Posted: Tue Jan 27, 2004 12:03 pm Post subject: patatrac! tutto corrotto! |
 |
|
Cavolo mi si è corrotto tutto!
ho dischi sia reiserfs che ext3 chi mi consiglia un modo quanto più sicuro per fare i check?
Ciao!
_________________
RTFM!!!!
e
http://www.comio.it
 |
|
| Back to top |
|
 |
emix
Veteran
Joined: 30 Nov 2003
Posts: 1014
|
| Posted: Tue Jan 27, 2004 12:04 pm Post subject: |
|
|
| Potresti avviare dal livecd ed eseguire fsck. |
|
| Back to top |
|
|
comio
Advocate
Joined: 03 Jul 2003
Posts: 2191
Location: Taranto
|
| Posted: Tue Jan 27, 2004 12:16 pm Post subject: |
|
|
fatto... anche se è scomparso "menu.lst" di grub ed inoltre il kernel non riesce a risolvere alcuni simboli mentre carica i moduli.
Come posso fare un emerge di TUTTO TUTTO per recuperare eventuali file corrotti nelle librerie?
Ciao!
(assumendo che gcc sia funzionante)
_________________
RTFM!!!!
e
http://www.comio.it
|
|
| Back to top |
|
|
IgaRyu
Guru
Joined: 23 Jan 2003
Posts: 302
Location: Verona
|
| Posted: Tue Jan 27, 2004 12:38 pm Post subject: |
|
|
| Quote: | Come posso fare un emerge di TUTTO TUTTO per recuperare eventuali file corrotti nelle librerie?
|
Proprio tutto tutto ?
ed auguri
Joe
_________________
One Flew East
One Flew West
Some Flew On The Kukool's Nest |
|
| Back to top |
|
|
comio
Advocate
Joined: 03 Jul 2003
Posts: 2191
Location: Taranto
|
| Posted: Tue Jan 27, 2004 1:45 pm Post subject: |
|
|
alla fine ho copiato la home ed ho piallato... che balle! Tutto per colpa dell'interruttore del mio case... (ha fatto un ascintilla  )
_________________
RTFM!!!!
e
http://www.comio.it
|
|
| Back to top |
|
|
neon
l33t
Joined: 04 Aug 2003
Posts: 759
Location: Catania, Italy, Europe
|
| Posted: Tue Jan 27, 2004 7:51 pm Post subject: |
|
|
mmm a me uno sbalzo ha fo**uto ld.so.config, me ne sono accorto perchè non partiva più niente  l'ho ripristinato ed ora funziona tutto...
Possibilmente è partito anche altro di cui ignorerò per sempre la mancanza...
ma chi se ne frega  un giorno avrò errori assurdi ed impazzirò
_________________
Io credo che le tecnologie siano moralmente neutrali fino a quando non le utilizziamo - William Gibson
LINEE GUIDA DEL FORUM |
|
| Back to top |
|
|
comio
Advocate
Joined: 03 Jul 2003
Posts: 2191
Location: Taranto
|
| Posted: Tue Jan 27, 2004 8:19 pm Post subject: |
|
|
uso la macchina in modo intensivo per fare simulazioni... l'ultima cosa è dover impazzire quando meno mi serve. Meglio se piallo ora e non se ne parla più!!!
Ciao
_________________
RTFM!!!!
e
http://www.comio.it
|
|
| Back to top |
|
|
motaboy
Retired Dev
Joined: 15 Dec 2003
Posts: 1483
|
| Posted: Tue Jan 27, 2004 10:21 pm Post subject: |
|
|
Con "qpkg" puoi fare il check md5 dei file per vedere se sono corrotti o no e per evitare di riemergere tutto.
Però tieni conto che:
1) a volte alcuni ebuild sovrascrivono gli stessi file forniti da altri perciò non sono attendibili.
2) Se si è fottuto il database dei pacchetti installati non so se riesci a ripristinarlo.
Bye! |
|
| Back to top |
|
|
cerri
Bodhisattva
Joined: 05 Mar 2003
Posts: 2957
Location: # init S
|
| Posted: Wed Jan 28, 2004 9:09 am Post subject: |
|
|
Ottimo il consiglio di qpkg, ma ti consiglio di non prendertela con il case bensì con il fs usato.
Per ext3 usa data=journal per dormire sonni tranquilli (e se usi ctrl strani, disabilita la cache).
_________________
Enjoy your freedom.
Sex is like hacking. You get in, you get out, and you hope you didnt leave something behind that can be traced back to you.
<----------------------->
Andrea Cerrito |
|
| Back to top |
|
|
bsolar
Bodhisattva
Joined: 12 Jan 2003
Posts: 2764
|
| Posted: Wed Jan 28, 2004 5:34 pm Post subject: |
|
|
| cerri wrote: | | Per ext3 usa data=journal per dormire sonni tranquilli. |
Il data journalling garantisce di non ritrovarsi i file pieni di immondizia, ma non che tutte le operazioni siano state eseguite. Questo lo farebbe un fs atomico ala reiser4, almeno sulla carta.
_________________
I may not agree with what you say, but I'll defend to the death your right to say it. |
|
| Back to top |
|
|
comio
Advocate
Joined: 03 Jul 2003
Posts: 2191
Location: Taranto
|
| Posted: Wed Jan 28, 2004 6:18 pm Post subject: |
|
|
io ho sempre usato reiserfs. Non mi lamento.
Vorrei sapere quando avremo il nuovo reisers4? e se il passaggio dal 3.6 sarà indolore.
Ciao!
_________________
RTFM!!!!
e
http://www.comio.it
|
|
| Back to top |
|
|
neon
l33t
Joined: 04 Aug 2003
Posts: 759
Location: Catania, Italy, Europe
|
| Posted: Wed Jan 28, 2004 7:55 pm Post subject: |
|
|
| bsolar wrote: | | Il data journalling garantisce di non ritrovarsi i file pieni di immondizia |
Il che è già una ottima cosa... (ho avuto modo di collaudare xfs senza data-journaling... file pieni di immondizia a tappo )
_________________
Io credo che le tecnologie siano moralmente neutrali fino a quando non le utilizziamo - William Gibson
LINEE GUIDA DEL FORUM |
|
| Back to top |
|
|
cerri
Bodhisattva
Joined: 05 Mar 2003
Posts: 2957
Location: # init S
|
| Posted: Wed Jan 28, 2004 8:25 pm Post subject: |
|
|
| bsolar wrote: | | Il data journalling garantisce di non ritrovarsi i file pieni di immondizia, ma non che tutte le operazioni siano state eseguite. Questo lo farebbe un fs atomico ala reiser4, almeno sulla carta. |
In linea teorica, quello che dici dovrebbe essere fornito da data=ordered, ma data=journaling garantisce in quanto le operazioni vengono scritte 2 volte su disco.
_________________
Enjoy your freedom.
Sex is like hacking. You get in, you get out, and you hope you didnt leave something behind that can be traced back to you.
<----------------------->
Andrea Cerrito |
|
| Back to top |
|
|
MyZelF
Bodhisattva
Joined: 25 Feb 2003
Posts: 2010
Location: Venice, Italy
|
| Posted: Wed Jan 28, 2004 9:03 pm Post subject: |
|
|
| cerri wrote: | | data=journaling garantisce in quanto le operazioni vengono scritte 2 volte su disco. |
2 volte? Più o meno...  (detta così sembra che in modalità journal ext3 effettui il mirroring dei dati)
| Quote: |
* journal mode
data=journal mode provides full data and metadata journaling. All new
data is written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both
data and metadata into a consistent state. This mode is the slowest
except when data needs to be read from and written to disk at the same
time where it outperform all others mode.
|
mentre con la modalità di default (data=ordered)
| Quote: |
* ordered mode
In data=ordered mode, ext3 only officially journals metadata, but it
logically groups metadata and data blocks into a single unit called a
transaction. When it's time to write the new metadata out to disk, the
associated data blocks are written first. In general, this mode
perform slightly slower than writeback but significantly faster than
journal mode.
|
(da /usr/src/linux/Documentation/filesystems/ext3.txt) |
|
| Back to top |
|
|
cerri
Bodhisattva
Joined: 05 Mar 2003
Posts: 2957
Location: # init S
|
| Posted: Wed Jan 28, 2004 10:10 pm Post subject: |
|
|
Esatto. Journal prima scrive sul journal, poi sui dati.
_________________
Enjoy your freedom.
Sex is like hacking. You get in, you get out, and you hope you didnt leave something behind that can be traced back to you.
<----------------------->
Andrea Cerrito |
|
| Back to top |
|
|
MyZelF
Bodhisattva
Joined: 25 Feb 2003
Posts: 2010
Location: Venice, Italy
|
| Posted: Wed Jan 28, 2004 10:35 pm Post subject: |
|
|
| cerri wrote: | | Esatto. Journal prima scrive sul journal, poi sui dati. |
Le maggiori garanzie sono date anche dal journaling dei dati oltre che dei metadati.
Però, come dice bsolar, non sono sicuro che ext3, anche in modalità journal, garantisca l'esecuzione atomica del flushing dei buffer / scrittura del journal, anzi. Ovvero un fallimento durante queste operazioni potrebbe portare comunque il filesystem in uno stato inconsistente e/o incoerente. |
|
| Back to top |
|
|
cerri
Bodhisattva
Joined: 05 Mar 2003
Posts: 2957
Location: # init S
|
| Posted: Thu Jan 29, 2004 7:24 am Post subject: |
|
|
| MyZelF wrote: | | Però, come dice bsolar, non sono sicuro che ext3, anche in modalità journal, garantisca l'esecuzione atomica del flushing dei buffer / scrittura del journal, anzi. Ovvero un fallimento durante queste operazioni potrebbe portare comunque il filesystem in uno stato inconsistente e/o incoerente. |
Il kernel può solo dire al controller di flushare le operazioni pending in scrittura, che di solito sono relative alle scritture sul journal. Un ctrl che "ignora" queste richieste può sempre portare a corruzione dei dati, ma c'è poco da fare (non c'è fs che tenga, solo legnate al produttore del ctrl).
In realtà il vantaggio di reiserfs4 non è quello di permettere il flushing, ma di avere un algoritmo che, a detta loro, permette la stessa sicurezza della modalità journal di ext3 senza dover necessariamente scrivere i dati 2 volte.
breve
| http://www.namesys.com/v4/v4.html wrote: | | Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice. |
contrario di breve
| http://www.namesys.com/v4/v4.html#journ_location wrote: | Fixed Location Journaling
A solution to this was adopted of first writing each atomic operation to a location on disk called the journal or log, and then, only after each atom had fully reached the journal, writing it to the committed area of the filesystem.
The problem with this is that twice as much data needs to be written. On the one hand, if the workload is dominated by seeks, this is not as much of a burden as one might think. On the other hand, for writes of large files, it halves performance because such writes are usually transfer time dominated.
For this reason, meta-data journaling came to dominate general purpose usage. With meta-data journaling, the filesystem guarantees that all of its operations on its meta-data will be done atomically. If a file is being written to, the data in that file being written may be corrupted as a result of non-atomic data operations, but the filesystem's internals will all be consistent. The performance advantage was substantial. V3 of reiserfs offers both meta-data and data journaling, and defaults to meta-data journaling because that is the right solution for most users. Oddly enough, meta-data journaling is much more work to implement because it requires being precise about what needs to be journaled. As is so often the case in programming, doing less work requires more code.
With fixed location data journaling, the overhead of making each operation atomic is too high for it to be appropriate for average applications that don't especially need it --- because of the cost of writing twice. Applications that do need atomicity are written to use fsync and rename to accomplish atomicity, and these tools are simply terrible for that job. Terrible in performance, and terrible in the ugliness they add to the coding of applications. Stuffing a transaction into a single file just because you need the transaction to be atomic is hardly what one would call flexible semantics. Also, data journaling, with all its performance cost, still does not necessarily guarantee that every system call is fully atomic, much less that one can construct sets of operations that are fully atomic. It usually merely guarantees that the files will not contain random garbage, however many blocks of them happen to get written, and however much the application might view the result as inconsistent data. I hope you understand that we are trying to set a new expectation here for how secure a filesystem should keep your data, when we provide these atomicity guarantees. |
| http://www.namesys.com/v4/v4.html#writing_twice wrote: | Writing Twice May Be Optimal Sometimes
Suppose that a file is currently well laid out, and you write to a single block in the middle of it, and you then expect to do many reads of the file. That is an extreme case illustrating that sometimes it is worth writing twice so that a block can keep its current location while committing atomically. If one writes a node twice in this way, one also does not need to update its parent and ripple all the way to the top of the tree. Our code is a toolkit that can be used to implement different layout policies, and one of the available choices is whether to write over a block in its current place, or to relocate it to somewhere else. I don't think there is one right answer for all usage patterns.
If a block is adjacent to many other dirty blocks in the tree, then this decreases the significance of the cost to read performance of relocating it and its neighbors. If one knows that a repacker will run once a week (a repacker is expected for V4.1, and is (a bit oddly) absent from WAFL), this also decreases the cost of relocation. After a few years of experimentation, measurement, and user feedback, we will say more about our experiences in constructing user selectable policies.
Do we pay a performance penalty for making Reiser4 atomic? Yes, we do. Is it an acceptable penalty? We picked up a lot more performance from other improvements in Reiser4 than we lost to atomicity, and so it is not isolated in our measurements, but I am unscientifically confident that the answer is yes. If changes are either large or batched together with enough other changes to become large, the performance penalty is low and drowned out by other performance improvements. Scattered small changes threaten us with read performance losses compared to overwriting in place and taking our chances with the data's consistency if there is a crash, but use of a repacker will mostly alleviate this scenario. I have to say that in my heart I don't have any serious doubts that for the general purpose user the increase in data security is worthwhile. The users though will have the final say. |
_________________
Enjoy your freedom.
Sex is like hacking. You get in, you get out, and you hope you didnt leave something behind that can be traced back to you.
<----------------------->
Andrea Cerrito |
|
| Back to top |
|
|
MyZelF
Bodhisattva
Joined: 25 Feb 2003
Posts: 2010
Location: Venice, Italy
|
| Posted: Thu Jan 29, 2004 9:05 am Post subject: |
|
|
| cerri wrote: | Un ctrl che "ignora" queste richieste può sempre portare a corruzione dei dati
|
Su questo non ci piove: hai perfettamente ragione... quello che intendevo dire, comunque, è proprio questo:
| cerri wrote: |
| http://www.namesys.com/v4/v4.html#journ_location wrote: |
Also, data journaling, with all its performance cost, still does not necessarily guarantee that every system call is fully atomic
|
|
|
|
| Back to top |
|
|
pinguinoferoce
Tux's lil' helper
Joined: 09 Sep 2003
Posts: 147
|
| Posted: Fri Jan 30, 2004 6:11 pm Post subject: |
|
|
posto xkè centra qualkosa con il topic ....
l' altro ieri ho emerso l' ultivo ppc-dev kernel , compilato ecc....
al riavvio con n' uovo kernel, bene,
poi compilo qualkosa e....
sembrava di avere la ram corrotta : i pacchetti si ricompilavano solo alla seconda volta che tentavo (forse ho sbagliato ad aggiungere al kernel l' opzione preemptible).
Poi, a causa di un problema di qemu ho riavviato con il pulsante off .
Bene, riavvio con il kernel della serie 2.4.2x (che usavo e che andava benissimo), ma quando monto la mia chiavetta usb mi da un errore di kernel (stesso risultato con il 2.6.x).
Purtroppo nn posso postare l' errore xke mi sto collegando con il pc di mio fratello .........
Pensate che il riavvio centri qualkosa con la xdita di file? |
|
| Back to top |
|
|
pinguinoferoce
Tux's lil' helper
Joined: 09 Sep 2003
Posts: 147
|
| Posted: Fri Jan 30, 2004 6:43 pm Post subject: |
|
|
ecco il messaggio di errore
----------------------------------------------------------------------------------------
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x14 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage: 00 00 00 00 00 00 20 00 ed cc 3c 30
usb-storage: Bulk command S 0x43425355 T 0x15 Trg 0 LUN 0 L 0 F 0 CL 6
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x15 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage: 00 00 00 00 00 00 00 00 00 00 00 00
usb-storage: Bulk command S 0x43425355 T 0x16 Trg 0 LUN 0 L 0 F 0 CL 6
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x16 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
Oops: kernel access of bad area, sig: 11
NIP: F13B841C XER: 00000000 LR: F13B8F7C SP: EDCC3C10 REGS: edcc3b60 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: FFF80006, DSISR: 40000000
TASK = edcc2000[3850] 'mount' Last syscall: 21
last math edcc2000 last altivec 00000000
GPR00: 00000000 EDCC3C10 EDCC2000 E43C1000 EDCC3D80 EDCC3D84 00000000 EDCC3CE0
GPR08: EDCC3D00 FFF80000 080003E8 00000000 22002222 1001EADC 00000000 00000000
GPR16: 00000000 10020000 10010000 10020000 EDCC3D00 EDCC3CE0 00000000 00000200
GPR24: EDCC3D84 EDCC3D80 EDCC3D00 E43C1000 EDCC3CE0 00000001 EDCC3C80 EDCDB4E4
Call backtrace:
F13B8F7C F13C128C C00456E0 C0045AD0 C005A860 C005ABD8 C005B14C
C00061DC 00000000 10009518 10002630 10003C5C 10003B88 10003FB4
10004FF0 0FEBE3A4 00000000
------------------------------------------------------------------------------------------- |
|
| Back to top |
|
|
shev
Bodhisattva
Joined: 03 Feb 2003
Posts: 4084
Location: Italy
|
| Posted: Fri Jan 30, 2004 7:37 pm Post subject: |
|
|
[OT]
| pinguinoferoce wrote: | | (forse ho sbagliato ad aggiungere al kernel l' opzione preemptible) |
Esatto, su ppc con kernel 2.6 è fortemente sconsigliata poichè non ancora matura e stabile.
[fine OT]
_________________
Se per vivere ti dicono "siediti e stai zitto" tu alzati e muori combattendo |
|
| Back to top |
|
|
|
Forum italiano (Italian)
