Newsgroup: it.comp.os.linux.sys
Titolo: Disattivare check del filesystem all'avvio

Salve a tutti.
A un serverino Debian è collegata via SCSI un'unità RAID, sulla quale è 
presente un'unità logica da circa 1,5 terabyte, utilizzata per dei 
backup. Il problema è che un fsck su quell'unità impiega moltissimo 
tempo, e quindi se il sistema decide che è arrivato il momento di farlo 
prima del mount all'avvio mi blocca il server per un bel po', magari 
proprio nel mezzo di qualche "corsa di manutenzione".
Ora, potrei certo disattivare il check periodico, ma comunque il 
contenuto di quell'unità è importante e pertanto sarebbe saggio farlo 
periodicamente in qualche altro modo.
Come si usa fare in questi casi? Una banale programmazione del check in 
crontab scegliendo un momento opportuno, niente di più astuto?
Tra l'altro, anche supponendo che il server non venga mai riavviato per 
mesi un check programmato di tanto in tanto non ci starebbe male...
Grazie.
-- 
Ciao,
   Marco.

 A un serverino Debian è collegata via SCSI un'unità RAID, sulla quale è
]zac[
Modifica il file inittab o quello che viene usato per avviare il sistema, e
guarda che cosa ABILITA il fsck, se è troppo contorno aggiungi un test di
presenza di un file.
Quando vuoi abilitare il fsck crei file, quando non lo vuoi lo rimuovi.
P.S. Il fsck nel crontab è una pessima idea, come da messaggio di warning
fsck.

 fsck.
E perché?
Nel man non trovo niente. Devo provare a lanciare fsck da crontab per 
vedere questo warning?
Strano però, anche cercando "fsck crontab" su Google non trovo niente di 
che, addirittura su Google Groups già il terzo risultato è questo tuo 
messaggio 8-).
-- 
Ciao,
   Marco.

 E perché?
Forse perche' il fs dovrebbe essere smontato per farlo? Ti piacerebbe che 
cron ti levasse da sotto i piedi il fs?

 Queste cose si fanno con tune2fs. Decidi quando o se fare il check.
Dipende dal file system. Se stiamo parlando di ext[2|3|4] e` corretto
usare tune2fs, su altri file system si usano altri comandi (sempre se
previsto)
Enrico

 Dipende dal file system. 
Mi sa che il check lo fanno solo i fs della serie extn.

 Mi sa che il check lo fanno solo i fs della serie extn.
Un check di consistenza al boot viene fatto sempre e comunque,
indipendentemente dal file system trattato. Tra questi, ext e`
l'unico[1] che forza un check approfondito dopo un tot di mount o un tot
di giorni
Enrico
[1] forse lo fa anche ReiserFS, ma non uso quel file system da decenni

 cron ti levasse da sotto i piedi il fs?
Davo per scontato che l'eventuale esecuzione in crontab sarebbe 
posizionata (temporalmente) in modo da non interferire con le operazioni 
su quel filesystem. Inoltre gli unici accessi a quel filesystem, per lo 
meno in orari non lavorativi, sono da parte di script che ho creato io, 
nei quali è sempre presente il controllo del mount prima di iniziare le 
operazioni; quindi al limite mi arriverebbe solo qualche mail di errore 
e gli script non andrebbero avanti.
Chiariti questi punti, quale comportamento adottate in genere in questi 
casi? Se non ho capito male, il tuo punto di vista è "fregatene del 
check se l'hardware e ok e il sistema funziona bene"...
-- 
Ciao,
   Marco.

 Davo per scontato che l'eventuale esecuzione in crontab sarebbe
]zac[
Davo per scontato che lo sforzo di fare una prova non fosse cosi enorme
(anche perché la cosa potrebbe dipendere dal tipo e versione del
filesystem):
fsck /dev/sda3
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/dev/sda3 is mounted.
WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?
P.S. Non è possibile smontare un filesystem in uso
PP.SS. Non è possibile rimontare in R.O. un filesystem che abbia degli
accessi in scrittura.

 accessi in scrittura.
Piu` che altro fsck lamenta lo stesso messaggio. In parole povere,
secondo fsck, per prevenire totalmente eventuali problemi, il file
system dovrebbe essere smontato e basta
Enrico

 SEVERE filesystem damage.
OK, questo lo so, ma come ho detto sono io a gestire i tempi di accesso 
a quel filesystem da parte dei miei script. Quindi io so che, ad esempio 
(ma invento perché ora non ricordo il crontab a memoria ;)), tutte le 
notti dall'una alle 5 non viene eseguita nessuna operazione che riguardi 
quel filesystem, e quindi sapendo che il check impiega due ore (questo 
purtroppo è vero, l'ho fatto oggi) posso programmarlo in 
quell'intervallo ogni mese, con uno script richiamato da crontab che 
smonti il fs, lanci fsck e poi rimonti il fs.
L'unica possibilità che il fs sia in uso a quell'ora è che il boss (che 
è l'unico ad avere accesso al backup tramite Samba oltre me, ma solo in 
lettura) sia rimasto a lavorare proprio quella notte e abbia proprio in 
quel momento bisogno di leggere file dal backup, ma sarebbe pura sfiga, 
e poi anche se succedesse pazienza, fallito l'umount si salta il check, 
si manda una mail di errore e si riprova alla prossima.
Era tutto qui il problema nell'avviare il check da crontab?
Pensavo che tu stessi parlando di un warning più specifico riguardo 
all'avvio da crontab.
Altrimenti, soluzioni alternative?
Grazie.
-- 
Ciao,
   Marco.

 Grazie.

 Formattare in ext4 ?
Hm, la vedo un po' azzardata... leggo che è stato dichiarato non 
sperimentale solo nel kernel 2.6.28, ma i pacchetti ufficiali per Debian 
Etch arrivano a 2.6.18... preferirei evitare campi minati :).
-- 
Ciao,
   Marco.

 
Non riesco per niente a comprendere il punto, se il filesystem di cui
fare/no fare il check non è quello di root basta disattivare il controllo
automatico in fstab o con tune2fs (se è ext2/3) i giorni o il numero di
boot a preferenza, e poi ogni tanto controllarlo manualmente, farlo fare a
cron è piuttosto insensato.
Se è quello di root cron è da evitare.

 cron è piuttosto insensato.
Il punto è che, IMHO, se un controllo può essere fatto in automatico in 
modo affidabile allora è meglio farlo così, piuttosto che affidarsi alla 
memoria e disponibilità di tempo umana.
-- 
Ciao,
   Marco.