[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fsck στο ξεκινημα. Χρειάζεται τελικά; Κάθε πότε;



> Τελικά κατέληξα στα εξής.
>
> tune2fs -c 100 -i 100d /dev/md0
> Τον έπεισα να μην κλεινει το πισι για οσο το δυνατον μεγαλύτερο διαστημα.

[ ... ]

> Οι προτασεις για partitions κλπ δεν αλλαζουν κατι. Η δομη ειναι η εξης. Ενας
> 80ρης για το λειτουργικο (αυτος ηταν τοτε διαθεσιμος) και 3x1,5TB σε raid5
> σε ενα partition, mounted στο /media/FileServer. Άρα δεν αλλάζει κάτι
> To fsck δεν το απενεργοποιω. Το φοβαμαι...

Το πρόβλημά σου είναι ότι το μηχάνημα πρέπει να περιμένει να γίνει fsck
σε ένα partition των 3.5TB (!) πριν αρχίσει να ανταποκρίνεται στα ping/ssh.

Επειδή το μηχάνημα είναι headless υπάρχει δηλαδή μία αβεβαιότητα
για περίπου μία ώρα (!) αν έχει "κολλήσει" ή κάνει fsck, πράγμα που οδηγεί
τον κάτοχο να κάνει hard reset αυξάνοντας τις πιθανότητες να γίνει
πραγματική ζημιά και να σου μπουν όλα τα 3.5 TB στο lost+found
(σύμφωνα με όσα έγραψε ο Θάνος για βίαιη διακοπή ενός fsck που
διορθώνει κάτι).

Αυτή η αναμονή από την άποψη του σχεδιασμού ενός πληροφοριακού
συστήματος είναι εντελώς παράλογη, δεδομένου ότι σε αυτό το
partition δεν υπάρχει τίποτα που να εμποδίζει το δίκτυο/ssh
να δουλέψει.

Η αλλαγή που έκανες απλά βάζει το πρόβλημα "κάτω από το χαλί"
δηλαδή απλά θα παρατηρείται πιο σπάνια, εξακολουθεί όμως να
υφίσταται.

Εφόσον δε θέλεις ούτε να αλλάξεις το partitioning, ούτε να βγάλεις
το md0 από τα auto-mounted partitions, ούτε να αλλάξεις το filesystem,
η μόνη λογική λύση είναι να απενεργοποιήσεις _εντελώς_ το fsck ρουτίνας
από το md0.

Αντί γι αυτό, μπορείς να κάνεις fsck manually πού και πού, ή μέσω ενός
cronjob ή κάτι τέτοιο. Τουλάχιστον με αυτό τον τρόπο ο χρήστης θα
μπορεί να κάνει ένα ssh (ή να μπει σε κάποιο web interface ή κάτι τέτοιο)
και να δει τί γίνεται, οπότε θα είναι πιο απίθανο να προξενήσει
μεγαλύτερη ζημιά.

Φυσικά η λύση του cronjob μπορεί να έχει λίγο πονοκέφαλο στο σχεδιασμό
αλλά υποθέτω ότι γνωρίζεις όλα τα processes που αγγίζουν το συγκεκριμμένο
partition και τις ανάγκες τους οπότε μπορείς να βρεις μια λογική λύση
(remount read-only στη χειρότερη περίπτωση).

Διαφορετικά, υπάρχει και η λύση του netconsole / serial console ώστε
πάλι ο χρήστης να μπορεί να δει τί γίνεται.

Γενικά, αβεβαιότητα για το σε ποιά κατάσταση βρίσκεται ένα σύστημα
για μία ώρα == bad user interface και αυτό είναι το πραγματικό πρόβλημα
που πρέπει να λύσεις (ανεξαρτήτως πώς).

Φιλικά,
Παντελής

Reply to: