"Daniel Kobza" <daniel.kobza@invalid.invalid> wrote in message
news:slrnbpfktr.a9p.daniel.kobza@pc3.dkobza.intra


> Suggerimenti?
Tutti quelli che ti hanno dato prima del mio arrivo sono giusti e
corretti ...

io posso solo aggiungere che se avessi voglia di rischiare stà per
uscire il reiser4 che si basa su transizioni atomiche, quindi in pratica
non dovrebbe essere possibilie corrompere nessun tipo di file anche se
lo spegnimento arriva durante la scrittura.

Pecchato che debba essere rilasciato a gironi o mesi, e che ovviamente
avrà bisogni di un bel periodo di prova.







--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

On Thu, 23 Oct 2003 13:12:28 GMT, Daniel Kobza
<daniel.kobza@invalid.invalid> wrote:


>raggiunti da punti rete. Sostengono inoltre che per anni hanno trattato
>allo stesso modo le macchine con NT4 senza mai aver avuto problemi, e
>*pretendono* che la nuova soluzione sia altrettanto insensibile agli
>spegnimenti brutali (queste sono parole loro).
non mi convince, non ho usato per molto tempo NT4, ma ti assicuro che
lo spegnimento alla brutta non e' gradito neppure da lui.

come minimo ti becchi la richiesta di controllare il fs al riavvio
successivo (che, a dire il vero in effetti si puo' disabilitare), ma,
sempre in base ai ricordi, prima o poi ti si pianta seriamente.
e a quel punto chiami il tecnico. Di buono c'e' che il fattaccio e'
possibile capiti raramente e quindi possa far credere si tratti di un
malfunzionamento dovuto non tanto allo spegnimento brutale, quanto al
"normale" funzionamento di NT.

Con linux la possibilita' che riavvi normalmente e' piu' bassina,
(ovvero e' piu' facile che chieda un intervento manuale anche per cose
di poco conto) anche se, mettendo tutto il possibile in ro+ext3+sync
potresti *forse* cavartela con interventi manuali nella stessa
frequenza (o forse meno) che con NT

.... non per demoralizzarti, ma hai a mano 'na bella pesca, specie per
il fatto che arrivati a questo punto, per come la vedo, ogni minimo
problema sara' colpa di linux ... che prima con NT funzionava tutto...

--
nebbia

Daniel Kobza wrote:

> Dunque, in qualsiasi momento (scelto arbitrariamente dal resp. di
> produzione, ma cmq a produz. ferma), un omino va presso il singolo PC
> con un laptop, si collega con cavo cross (staccando quello del PLC, che
> *dovrebbe* essere in STOP), lancia via telnet uno script in perl che
> genera la reportistica (in html e/o plain text), che poi viene scaricata
> sul laptop. Lo so, terribile, ma queste erano le specifiche del cliente.

Vabbe`, ma se la corrente viene staccata durante la
scrittura di dati, ammesso che non via siano problemi
con il FS, il DB risulta quantomeno incompleto.

Questo immagino sia accettabile, dato che e` inevitabile.

Quindi, direi, che la soluzione e` usare un FS che non
si incasina, ma semplicemente lascia il file rovinato.

Oppure non usare affatto un FS.

bye,

--
Piergiorgio Sartor

Skull wrote:

> Per il resto, la corruzione del journal non dovrebbe accadere mai (almeno
> per ext3 "standard", se si usa la ext3 con i btree è un altro discorso, ma
> lì vuol dire andarsele a cercare).

Scusa, ma se il journal viene scritto a meta`?

Se il commit non avviene, non ci sono santi
che tengano, a mio avviso...

bye,

--
Piergiorgio Sartor

Maurizio - Tannoiser wrote:

> E` vero, ma dovrebbe essere una condizione eccezionale. Almeno con la
> forma di journaling "ordered". A quel punto, dovrebbe verificarsi solo
> in caso di error on disk. Insomma, io ne ho visti proprio pochi
> (tendenti allo zero). E` cosi` sfortunata quella installazione?

Mi e` successo solo una volta, senza conseguenze alcune.

> Se no, vale la pena di montare il journal in writeback mode?

Nel caso in questione potrebbe andare bene, anche se
io tendenzialmente eliminerei complentamente il FS.

bye,

--
Piergiorgio Sartor

Marco Cavaliere wrote:

> io posso solo aggiungere che se avessi voglia di rischiare stà per
> uscire il reiser4 che si basa su transizioni atomiche, quindi in pratica
> non dovrebbe essere possibilie corrompere nessun tipo di file anche se
> lo spegnimento arriva durante la scrittura.

In base a quale magia?

Voglio dire, se non e` scritto, non e` scritto...

Forse, e dico forse, il FS non si corrompe, ma
anche in questo dubiterei...

bye,

--
Piergiorgio Sartor

Sgranocchiando in cranio di Piergiorgio Sartor, vi trovai inciso:

> Skull wrote:
>
>> Per il resto, la corruzione del journal non dovrebbe accadere mai (almeno
>> per ext3 "standard", se si usa la ext3 con i btree è un altro discorso, ma
>> lì vuol dire andarsele a cercare).
>
> Scusa, ma se il journal viene scritto a meta`?

Le operazioni di scrittura sul journal sono atomiche e sequenziali,
teoricamente, solo l'ultima può rimanere sospesa (e basta che il recovery
la ignori...)

> Se il commit non avviene, non ci sono santi
> che tengano, a mio avviso...

se il commit non avviene, è sufficiente che questo venga effettuato
all'atto del recovery del FS, se le informazioni loggate sono sufficienti.
In caso non fosse possibile, il recovery si occupa del rollback al
precedente stato coerente.

Salvo difetti di implementazione, ovvio...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
The Skull says:
Stop VeriSign. Go to http://www.whois.sc/verisign-dns/
* The most stupid thing since Microsoft Network... <g> *

Piergiorgio Sartor <piergiorgio.sartor@nexgo.remove.this.de> wrote:
> Skull wrote:
>
>> Per il resto, la corruzione del journal non dovrebbe accadere mai (almeno
>> per ext3 "standard", se si usa la ext3 con i btree è un altro discorso, ma
>> lì vuol dire andarsele a cercare).
>
> Scusa, ma se il journal viene scritto a meta`?
>
> Se il commit non avviene, non ci sono santi
> che tengano, a mio avviso...

Da quanto ho capito, ll journal può rimanere scritto a metà, ma solo
l'ultima parte. Il replay verrà fatto con tutti i metadati
(nel journal) precedenti l'ultimo checkpoint.
Si possono perdere gli ultimissimi aggiornamenti alla struttura
del fs, ma non c'è corruzione.

--
Lorenzo

Marco Cavaliere <marcomerit@hotmail.com> wrote:
>
> io posso solo aggiungere che se avessi voglia di rischiare stà per
> uscire il reiser4 che si basa su transizioni atomiche, quindi in pratica
> non dovrebbe essere possibilie corrompere nessun tipo di file anche se
> lo spegnimento arriva durante la scrittura.

Questo lo fa anche ext3 di default.

--
Lorenzo

Skull wrote:

> Le operazioni di scrittura sul journal sono atomiche e sequenziali,
> teoricamente, solo l'ultima può rimanere sospesa (e basta che il recovery
> la ignori...)

Ma atomiche cosa vuol dire?
Relativamente al kernel.

Se devi scrivere due blocchi, li passi all'HD e` va via
l'alimentazione, i blocchi semplicemente non risultano
scritti, non ci sono santi che tengano.

> se il commit non avviene, è sufficiente che questo venga effettuato
> all'atto del recovery del FS, se le informazioni loggate sono sufficienti.

Questo credo sia il problema, cioe` il fatto che niente
e nessuno puo` garantire una consistenza, nelle migliori
delle ipotesi risulta possibile capire che vi e` una
inconsistenza e _tentare_ un recovery.

> In caso non fosse possibile, il recovery si occupa del rollback al
> precedente stato coerente.

Ma e` possibile trovare incosistenze, in particolore nei timestamp.

Evento forse raro, ma possibile.

bye,

--
Piergiorgio Sartor