On Thursday 23 October 2003 15:12, Daniel Kobza wrote in message
<slrnbpfktr.a9p.daniel.kobza@pc3.dkobza.intra>:

> Suggerimenti?

Dei dati acquisiti poi cosa ne viene fatto? Dove vengono elaborati? Come
vengono trasferiti?

--
"It is not enough to succeed.**Others*must*fail."
Linux Registered User #301571, running Gentoo
Memeber of Luganega - Linux User Group Crema (IT)
http://filibusta.crema.unimi.it/

On Thu, 23 Oct 2003 13:12:28 GMT, Daniel Kobza wrote:

> Suggerimenti?

Ricapitolando potrsti fare:

- eliminare syslog e tutto quello che va a scrivere informazioni in piu'
sul disco.
- Montare il maggior numero di filesystem in ro.
- Per i filesystem che non sono in ro, prevedere un mount sincrono o
uno script che chiama sync ogni mezzo secondo.
- Impostare il postgress in modalita' sincrona.
- Impostare la risposta "y" automatica a fsck.
- Impostare un cron job che copi il database e tutti i dati importanti
ogni tot tempo, im modo che se si sputtanano i file che contengono il
database riesci a ripristinare quelli di 5 min prima, limitando i
danni.
- Inserire in ogni pc un santino di S. Antonio.

cosi dovresti essere *abbastanza* sicuro, al limite se propio perdi dei
dati importanti, perdi solo pochi minuti di lavoro, dato che c'e' la
copia di riserva fatta dal cronjob.

cya
Banana

On Thu, 23 Oct 2003 13:12:28 GMT, Daniel Kobza wrote:
> 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).

Fermo restando i consigli che gia` ti hanno dato, in larga parte
condivisibile, su questa sezione _MENTONO_.

E' dimostrato e dimostrabile.

ps:
se usi ext3, e journali, _NON_ dovrebbe in fsck, visto che il file
system e` consistente. Perche` a te succede? Non stiamo parlando del
fsck maximal mount (da disabilitare), vero?

--
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
An NT server can be run by an idiot, and usually is.

Maurizio - Tannoiser wrote:

> se usi ext3, e journali, _NON_ dovrebbe in fsck, visto che il file
> system e` consistente. Perche` a te succede? Non stiamo parlando del
> fsck maximal mount (da disabilitare), vero?

Non e` proprio esatto.

Al momento del mount di ext3, in caso di problemi,
viene fatto il recovery del journal.
Se pero` vengono trovate incosistenze nel journal
(a volte succede), parte fsck...

bye,

--
Piergiorgio Sartor

In un messaggio del Thu, 23 Oct 2003 13:12:28 GMT Daniel Kobza scriveva:

> Salve, scusate se vi tedio, ma ho un problema singolare, vorrei un
> parere e magari sapere se esiste una qualche soluzione tecnica.

> La società in cui lavoro ha installato presso un cliente una 20ina di
> macchine linux (Debian Woody) che acquisiscono dati da altrettanti PLC
> (tramite socket TCP/IP), PLC che pilotano delle linee di montaggio. Non
> è la prima volta che usiamo linux in questo ambito, e non abbiamo mai
> avuto problemi.
Non me ne intendo molto di queste cose ma collegare le macchine ad un
relais (si scrive cosi'?) e poi fare in modo che agendo sul relais la
singola macchina si comporta come se, sotto UPS, ricevesse la richiesta
di shutdown? Non so se cio' che ho scritto e' fantascienza ma e' la
prima cosa che mi e' venuta in mente.

--
| Pierluigi De Rosa (thorin@durin.khazad-dum.net). |
| CSLUG: http:/cslug.linux.it |
| email: info@cslug.linux.it |
| IRC: irc.freenode.net #cslug, #linux-cazzeggio |

Sgranocchiando in cranio di Piergiorgio Sartor, vi trovai inciso:

>> se usi ext3, e journali, _NON_ dovrebbe in fsck, visto che il file
>> system e` consistente. Perche` a te succede? Non stiamo parlando del
>> fsck maximal mount (da disabilitare), vero?
>
> Non e` proprio esatto.
>
> Al momento del mount di ext3, in caso di problemi,
> viene fatto il recovery del journal.
> Se pero` vengono trovate incosistenze nel journal
> (a volte succede), parte fsck...

Afaik, succedeva solamente su macchine RH 7.3 o AS 2.1 con il kernel
originale, che aveva il supporto a ext3 bacato che ogni tanto sputtanava
il journal.
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).
Almeno, AFAIK...
Se poi qualcuno ha info in più prego postare...


Hola...

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

Rispondo a Piergiorgio, ma cmq ringrazio tutti per i suggerimenti,
alcuni dei quali avevo già attuato (come mettere PGFSYNC=Y per
PostregreSQL e montare il fs del db con l'opt. sync, che cmq è
equivalente).

Nell'articolo <3f97df60$0$265$4d4ebb8e@read.news.de.uu.net>, Piergiorgio
Sartor ha scritto:
>
> Domanda:
>
> questi PC acquisiscono dati dai PLC e li memorizzano
> su HD tramite il DB.
>
> Cosa succede a questi dati in seguito?
>
> Voglio dire vengono pescati, riletti, cosa se ne fanno?

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.

> Quanto spazio occupano questi dati?

Il sistema acquisice dal PLC l'immagine di una 40ina di registri ogni 30
secondi e ne traccia le variazioni. In funzione dell'andamento
produttivo, si può arrivare a circa 30 tpm, con un occupazione di spazio
tra i 7 e i 15 MB/giorno (del solo DB, esclusi i report prodotti), lo
svecchiamento è bimestrale.

Cmq, per sicurezza ho implementato un wrapper che scrive in un file di
testo (messo in una partizione rw dove c'è solo questo file) qualsiasi
istruzione SQL passata al DB, in modo da avere una sorta di redo log in
formato plain text e processabile come file di spool da psql. Adesso
stiamo valutando la possibilità di eliminare Postgres dai singoli PC e
utilizzare questo file (o qualcosa di simile) per rigenerare le
transazioni su un host "affidabile" che raccoglierà tutti i file
prelevati "manualmente" dai vari PC dall'omino di cui sopra. Abbiamo
pensato anche ad una generazione "multiplexata" dei file di spool (cioè
tante scritture in parallelo, in modo da avere più file nel caso uno si
corrompa), ma il dubbio è che il maggior overhead aumenti il rischio di
incasinamento del fs. Abbiamo anche pensato di usare una partizione per
file. In ogni caso, alla fine si complicherebbe l'operazione di trasf.
attuata dall'omino (quale dei file è valido e deve essere trasferito?).

L'ostacolo principale è cmq. il cliente, che vuole ogni PC totalmente
autonomo.

Saluti,
Dan

--
s/invalid.invalid/libero.it/
spam -> dakob@tin.it

On Thu, 23 Oct 2003 17:11:13 +0200, Piergiorgio Sartor wrote:
> Al momento del mount di ext3, in caso di problemi,
> viene fatto il recovery del journal.
> Se pero` vengono trovate incosistenze nel journal
> (a volte succede), parte fsck...

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?

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

--
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
sigfault

"Daniel Kobza" <daniel.kobza@invalid.invalid> ha scritto nel messaggio
news:slrnbpfktr.a9p.daniel.kobza@pc3.dkobza.intra. ..
.........
> Il problema è che le macchine che effettuano l'acquisizione dati vengono
> sistematicamente spente dal personale operaio (che agisce su un
> interruttore generale che disenergizza tutto il settore, quindi linea di
> montaggio, PLC e PC) senza effettuare la procedura di shutdown, per cui
> molto spesso all'avvio il sistema richiede la riparazione interattiva
> del filesystem (con enorme disapprovazione del cliente, perchè i PC non
> essendo presidiati rimangono fermi e non leggono più i dati dal campo).
>
> Abbiamo raccomandato al cliente di effettuare sempre la procedura si
> shutdown, ma la risposta è stata del tipo "non se ne parla nemmeno",

Prelevare l' alimentazione dei PC a monte degli interruttori delle linee di
montaggio ?
Che problemi gli vengono dal tenere alimentati i PC con le linee
deenergizzate ?
--------

Sergio Bianchi

Il Thu, 23 Oct 2003 13:12:28 +0000, Daniel Kobza ha scritto:


>
> Suggerimenti?

Installa APMD su tutti i PC.
Colleghi TUTTI i cavetti di spegnimento insieme comandati da un'unico
tasto messo IN FIANCO all'interruttore generale.
Prima il tastino dei PC. Aspettano 60 secondi... e poi quello generale.
La spesa è tutta in piattina... e anche se è un'industria Kilometrica sono
50 ¤ al massimo!

Comunque sia... se non volete perdere il cliente e NON VUOLE modifiche
rispetto a prima, mettete nel case di ogni PC un UPS da 300 Watt, sono
piccolissimi e ci stanno! Loro spengono il generale e i PC fanno lo
shutdown dopo qualche minuto.
Degli UPS di questo tipo costano veramente POCHISSIMO, ottima figura con
il cliente... e voi SIETE BELLI SICURI E TRANQUILLI.
Ciao...

Daniele