Newsgroup: it.comp.os.linux.sys
Titolo: Ho fatto una discreta 'minchiata' ...

 
Hai un qualche utente "sudato" ? cioe' abilitato a fare poerazioni di 
amministrazioni tramite sudo ?
potrebbe essere una soluzione, altre al momento non me ne vengono.
ciao
	MaX

 Schissi ctrl-alt-del (se non lo hai disattivato).
Uh, si, in effetti ...


 ciao, f.
io invece direi che puoi' spegnerlo "cosi'", senza tanti problemi, 
proprio in virtu 'del fatto che si tratta di un server del genere.
-- 
<empty signature>

 proprio in virtu 'del fatto che si tratta di un server del genere.
si si, la cache del controller la svuoti te vero?
la consistenza ti e' sconosciuta? 

 la consistenza ti e' sconosciuta? 
Per quello esiste la batteria di backup della cache direttamente sul
controller, quindi i dati vengono trasferiti sui dischi al ripristino
dell'alimentazione.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4


uff. Io ho _sempre_ le magic keys abilitate. alt+stamp+s, alt+stamp+u e 
alt+stamp+b e tutto fila sempre liscio.
-- 
il capitano dei carabinieri chiede a un appuntato: "quanto fa 1+1"
l'appuntato: "3"
I colleghi in coro "gli dia un'altra chance. Gli dia un'altra chance!"
Il capitano ci riprova. Quanto fa "2+1".
l'appuntato: "3"
I colleghi in coro "gli dia un'altra chance, gli dia un'altra chance!"

 alt+stamp+u e alt+stamp+b e tutto fila sempre liscio.
questo e' un altro discorso, fai bene a tenerle abilitate.
Non tutti i controller scsi hanno la pila gia' montata, alcuni (vedi 
l'adaptec montato dai Proliant ML110G2 di HP) hanno solo il pettine di 
collegamento, se vuoi la pila devi aggiungerla.

 alt+stamp+b e tutto fila sempre liscio.
Il fatto che sia sempre filato tutto liscio non implica che debba sempre
andare così.
Meglio non approfittare della buona sorte se non se ne ha l'effettiva
necessità.


 alt+stamp+b e tutto fila sempre liscio.
Ciao,
 e per essere piu' sicuri anche alt+stamp+e e alt+stamp+i prima, cosi' tra
"s" e "u" sei sicuro che nessuno scrive piu' nulla e inoltre hai la
garanzia che l'umount funziona.
 Ciao
 Federico


puo' andar bene, anzi e' sicuramente meglio.
Per quanto riguarda il fatto che umount potrebbe non funzionare non 
saprei. Non so se "alt+stamp+u" fa unmount e mount anzi non credo proprio.
Ad esempio, "mount -o remount,ro /dev/blabla" dovrebbe funzionare anche 
se la periferica e' occupata.
-- 
Massimiliano


Uff :-)
ritorno al concetto iniziale del post:
mettiamo pure che tu NON abbia la batteria tampone.
In questa situazione il controller SCSI si comporta, peggio, meglio o 
alla stessa maniera di un controller IDE? Non conosco bene tutte le 
specifiche, ma ho visto che in "burst mode" anche IDE usa una cache.
Pertanto possiamo dire il controller SCSI non si comporta peggio del 
controller IDE.
Pertanto, il concetto che volevo esprimere e' che non ha senso dire che 
non vuoi causare un reboot improvviso poiche' il server e' cosi' e coli'.
-- 
Massimiliano.



Ciao,
 se qualche processo ha file aperti in scrittura, credo che il remount
*debba* fallire.  D'altra parte, la "write" non ti puo' rispondere
"read-only filesystem" ...
 Ciao
 Federico

 "read-only filesystem" ...
infatti che t'avevo detto. Ma tu non mi volevi credere :) :) :) :)
e' curioso invece che quando usi: alt+stamp+u, il comando mount ti dice 
ancora che ilfilesystem e' montato RW ma in realta' non e' vero.
-- 
Massimiliano

 ancora che ilfilesystem e' montato RW ma in realta' non e' vero.
Ciao,
 ne discutevo proprio in questi giorni, forse su un altro ng ...
La fonte certa e' /proc/mounts !!
Il mount guarda il file /etc/mtab, che normalmente funziona ... Pero', 
quando la / viene rimontata in sola lettura, il file /etc/mtab non puo' 
piu' essere aggiornato ...
Guarda negli script di startup del tuo sistema, scommentto che prima di 
dare il "mount -a" c'e' un bel "rm /etc/mtab" !!
Un'altra opzione, non molto usata, e' quella di avere /etc/mtab come link 
a /proc/mounts, invece di un file ordinario.
 Ciao
 Federico

 a /proc/mounts, invece di un file ordinario.
Che però può creare notevoli problemi (per esempio con dm) ed è pertanto
sconsigliato.


 La fonte certa e' /proc/mounts !!
mannaggia giusto. Anche io discutevo alcuni giorni fa del grande 
vantaggio di avere il pseudo-filsystem (cosa che manca ancora in qualche 
vecchio unix)
Potrei anche darmi una svegliata...
-- 
Massimiliano.

 "read-only filesystem" ...
Perché no?
Non vedo una ragione per cui un remount non debba poter essere forzato, che
poi l'opzioncina non ci sia _ora_, è tutto un altro paio di maniche.
Ciao,
-- 
 Daniele Orlandi                                                        つづく

  ne discutevo proprio in questi giorni, forse su un altro ng ...
]zac[
Forse? sento un discreto fischio alle orecchie.

 poi l'opzioncina non ci sia _ora_, è tutto un altro paio di maniche.
Ciao,
 piacerebbe anche a me un'opzione del genere, ma purtroppo non e' 
solo una questione di kernel ... e' un problema di standard: lo standard 
attuale non prevede che la write possa fallire perche' il fs e' RO!
Quindi non basta aggiungere due rughe nel kernel ... poi bisogna 
modificare tutti i programmi per Linux ... cioe', no, non tutti! Solo 
quelli che ogni tanto scrivono su disco :-))
 Ciao
 Federico
#====================================================================#
 Unix _is_ user-friendly ...
 it's just very selective about who its friends are!
#====================================================================#

On Tue, 25 Oct 2005, it was written:

Oh bella, allora la telepatia esiste :-))
 Ciao
 Federico

 attuale non prevede che la write possa fallire perche' il fs e' RO!
Io credo che Daniele stesse cercando di dire un'altra cosa. E credo che 
abbia ragione ;)
Io credo che lui stesse dicendo (mi corregga se sbaglio):
e' possibile avere sulla macchina un dispositivo che a 200 km orari ti 
permette di espellere tutte e 4 le ruote :-)
Perche' no. Tecnicamente e' possibile avere tale dispositivo.
Certamente, per ovvi motivi, non lo si fa.
Diciamo che l'umount non si fa perche' si vuole essere rispettosi del 
programma che svolge operazione di scrittura, ma se volessimo essere 
piu' cafoni non ci sarebbe alcun limite tecnico. Il limite e' stato 
implementato a posteriori per evitare problemi.
D'altra parte, tu dici: "il programma non puo' risponderti che non puo' 
piu' scrivere". Ma il programma cosa fa se tu estrai un floppy o un 
disco usb sul quale lui sta scrivendo sopra? In fondo e' un umount anche 
questo :P
-- 
Massimiliano.

 quelli che ogni tanto scrivono su disco :-))
Non c'è da modificarli, ogni programma ben fatto sa che se write() < 0 c'è
qualcosa che non ha funzionato...


 Io credo che lui stesse dicendo (mi corregga se sbaglio):
un esempio piu' decente:
Perche' i defunct restano li'?
Tecnicamente e' possibilissimo far si che il kernel faccia sparire i 
defunct, ma non lo si fa, non per una questione di stile o di standard, 
ma perche' non si vuole che i PID vengano riutilizzati fintanto che ci 
puo' essere un parent che ha quei pid associati come child e gli puo' 
mandare un sigkill quando gli pare a piace :)
Ma, appunto, tecnicamente non e' impossibile. C'e' un perche' derivante 
da una scelta e non derivante da un limite tecnico nel poter fare una cosa.
-- 
Massimiliano.

 c'è qualcosa che non ha funzionato...
Uhm ... ogni programma ben fatto, in alcune circostanze, puo' preoccuparsi 
di capire cosa e' successo ...
Cmq, sono d'accordo che in casi di emergenza potrebbe far comodo, pero', 
come dicevo prima, c'e' sempre killall (o le magic system request).
Quello che veramente mancava, e finalmente l'hanno messo nel kernel 2.6, 
era la rimozione forzata dei moduli ... peccato che, se un modulo e' 
bacato, la rimozione forzata serva comunque a poco ...
 Ciao
 Federico
#====================================================================#
 > Linux is not user-friendly. 
 It _is_ user-friendly.
 It is not ignorant-friendly and idiot-friendly.
#====================================================================#