Ανάκτηση Ανοικτών Αρχείων στο Linux

Διαγράψατε ένα πολύτιμο αρχείο που όμως χρησιμοποιείται ακόμα; Μάθετε πώς μπορείτε να το «σώσετε»!

Του Παντελή Κουκούσουλα

Είναι παρασκευή βραδάκι και το τηλέφωνο χτυπάει επίμονα. «Τι ωραία», σκέφτεσαι, «κάποιος/κάποια θα με θυμήθηκε και θέλει να βγούμε για καφέ....». Τον ενθουσιασμό διακόπτει απότομα η τρεμάμενη φωνή του φίλου/πελάτη από την άλλη μεριά της γραμμής: «Γιατρέ, σώσε με σε παρακαλώ! Μόλις έγινε κάτι φοβερό! Τα δεδομένα των πελατών μου! Η επιχείρησή μου κινδυνεύει!» (Σημ: «γιατρέ» φωνάζει κάποιος χαϊδευτικά έναν linux admin όταν θέλει κάποια χάρη ή είναι απελπισμένος). Η απώλεια δεδομένων είναι δυστυχώς μια κατάσταση με την οποία οι περισσότεροι έμπειροι χρήστες / admins έρχονται αντιμέτωποι αρκετές φορές στη διάρκεια της επαγγελματικής και μη πορείας τους, είτε πρόκειται για δικά τους δεδομένα, είτε άλλων. Όσο κι αν βοηθούν οι καλά οργανωμένες και εκτελεσμένες πρακτικές backup, η χρήση του “κάδου ανακύκλωσης” και το “alias rm='rm -i'“ για τον root, πάντα θα υπάρχουν περιπτώσεις που η (προσπάθεια για) ανάκτηση είναι μονόδρομος.

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

Καθώς η ανάκτηση δεδομένων είναι περισσότερο δεξιότητα παρά θεωρητική γνώση, κάθε άρθρο της σειράς θα συνοδεύεται από μία εικονική μηχανή για Qemu/KVM στο συνοδευτικό DVD του περιοδικού, στην οποία μπορείτε άφοβα και με ασφάλεια να αναπαράγετε και να πειραματιστείτε με ακόμα και τα πιο «επίφοβα» σενάρια που παρουσιάζονται, κάτι που ο γράφων συνιστά ανεπιφύλακτα.

Βασικές Γνώσεις

Στο πρώτο άρθρο της σειράς, θα ασχοληθούμε με την ανάκτηση αρχείων που διαγράψαμε κατά λάθος, αλλά υπάρχει κάποια διεργασία που τα διατηρεί ακόμα ανοιχτά, π.χ., ένα video ή αρχείο ήχου που παίζει ακόμα, ένα log file που γίνεται ακόμα append, ένα loop-mounted iso, ή ακόμα και ένα αρχείο κειμένου που παραμένει ανοιχτό στο “less”. Στην περίπτωση αυτή, η ανάκτηση είναι 100% δυνατή. Για να καταλάβουμε το γιατί, είναι χρήσιμο να ρίξουμε μια κλεφτή ματιά στο τι συμβαίνει στο “παρασκήνιο” με τα αρχεία μας.

Κάθε αρχείο αναπαρίσταται στο δίσκο με μια δομή που ονομάζεται “inode” (και περιέχει την πληροφορία για το πού θα βρούμε τα δεδομένα του αρχείου στο δίσκο). Τα inodes αναγνωρίζονται από τον αριθμό τους και όχι από κάποιο αναγνώσιμο από άνθρωπο όνομα, μεταξύ άλλων και για το λόγο ότι ένα αρχείο/inode μπορεί να έχει παραπάνω από ένα ονόματα εντός του ίδιου συστήματος αρχείων. Tα ονόματα αυτά (γνωστά και ως “hard links”) διατηρούνται στο δίσκο σε δομές που ονομάζονται «καταχωρήσεις καταλόγου» (directory entries) οι οποίες περιέχουν τον αριθμό του inode του αρχείου που αντιστοιχεί στο όνομα (ή όπως λέμε “δείχνουν” προς το inode του αρχείου). Όταν μία διεργασία ζητήσει το «άνοιγμα» ενός αρχείου για διάβασμα ή γράψιμο, το Linux κατασκευάζει και διατηρεί στη μνήμη μια δομή δεδομένων που ονομάζεται “file descriptor” (struct file *), που περιέχει μεταξύ άλλων και τον αριθμό του inode που αντιστοιχεί στο αρχείο (βλ. Σχήμα). Στην πράξη τα πράγματα είναι αρκετά πιο πολύπλοκα, αλλά αυτό το απλοποιημένο μοντέλο αρκεί για να καταλάβουμε το πώς δουλεύουν τα παρακάτω.

Το σημαντικότερο που πρέπει να θυμόμαστε από αυτό το άρθρο είναι ότι το Linux δεν σβήνει το inode ενός αρχείου όσο το αρχείο χρησιμοποιείται (όσο δηλαδή υπάρχουν file descriptors που δείχνουν σε αυτό). Το μόνο που σβήνεται άμεσα όταν γράψουμε rm (ή unlink() μέσα από κώδικα C) είναι το directory entry που αντιστοιχεί σε αυτό το inode. Παρεμπιπτόντως, αυτός είναι και ο λόγος που μπορούμε να αναβαθμίσουμε το μεγαλύτερο μέρος μιας διανομής Linux χωρίς reboot. Οι υπάρχουσες διεργασίες συνεχίζουν να χρησιμοποιούν τις παλιές βιβλιοθήκες παρόλο που αυτές είναι θεωρητικά “σβησμένες” από το δίσκο, μέχρι να ολοκληρωθεί η εκτέλεσή τους.

Αν θέλουμε να ανακτήσουμε ένα ανοιχτό αρχείο μπορεί να θέλουμε να βεβαιωθούμε ότι η διεργασία που το κρατάει ανοιχτό (και ως εκ τούτου εμποδίζει τη διαγραφή του) δε θα τερματίσει προτού ολοκληρωθεί η ανάκτηση. Αυτό μπορούμε να το κάνουμε στέλνοντας στη διεργασία το σήμα STOP. (π.χ., kill -STOP
). Το σήμα STOP είναι ένα «ειδικό» σήμα, υπό την έννοια ότι απευθύνεται ουσιαστικά στο δρομολογητή διεργασιών (scheduler) του Linux και του λέει να μη δίνει πλέον χρονομερίδιο στη διεργασία μας. Επειδή η διαπραγμάτευση γίνεται απευθείας με τον πυρήνα, η διαδικασία αυτή θα πετύχει ανεξάρτητα από τον κώδικα της διεργασίας (αντίθετα με άλλα σήματα τα οποία τα διαχειρίζεται η ίδια η διεργασία και ως εκ τούτου μπορούν να έχουν απρόβλεπτα αποτελέσματα).

Οπλισμένοι λοιπόν με τις παραπάνω γνώσεις, ας δούμε τώρα μερικά σενάρια ανάκτησης.

Σενάριο 1: “Kατέβασμα” ενός Flash Video

Ας πούμε ότι έχετε ανοιχτό ένα browser και βλέπετε ένα βιντεάκι μουσικής στο youtube παρέα με το έτερο ήμισυ. “Τι ωραίο τραγούδι αγάπη μου” σας λέει, «μπορείς σε παρακαλώ να μου το μετατρέψεις σε ogg για το φορητό μου player;». «Φυσικά» λέτε εσείς και φουσκώνετε από περηφάνεια που για άλλη μια φορά θα δείξετε τις ικανότητές σας στο Linux. Αυτό γιατί γνωρίζετε ότι το libflashplayer αποθηκεύει προσωρινά τα αρχεία των video στο /tmp, οπότε στο Linux το «κατέβασμα» είναι απλά ένα copy (όταν φυσικά το video έχει «φορτώσει» πρώτα τελείως).

Κρατώντας λοιπόν τον browser ανοιχτό, ανοίγετε ένα τερματικό και κοιτάτε στο /tmp για αρχεία με όνομα της μορφής FlashXXΧΧΧΧΧΧ, αλλά τίποτα! «Περίεργο» σκέφτεστε, «ας ρίξω μια πιο καλή ματιά». Αυτό μπορεί να γίνει με την εντολή lsof, η οποία εμφανίζει όλα τα ανοικτά αρχεία μαζί με τις διεργασίες που τα χρησιμοποιούν. Φιλτράρωντας (grep) για ότι περιέχει τη λέξη FlashX παίρνουμε το εξής:

$ lsof | grep FlashX

npviewer. 5035 ... /tmp/FlashXXQ5VQQz (deleted)

Αχά! Από ότι φαίνεται το libflashplayer πλέον διαγράφει το όνομα του αρχείου του video (ίσως για να «κρύψει» τα αρχεία που χρησιμοποιεί ή για να βεβαιωθεί ότι δεν θα αφήσει (πιθανόν ενοχοποιητικά) “σκουπίδια” πίσω του αν κλείσει απότομα, ποιος ξέρει). Η παραπάνω εντολή ουσιαστικά μας λέει ότι η διεργασία με αριθμό 5035 και όνομα που ξεκινά από “npviewer.” έχει ανοιχτό το «σβησμένο» αρχείο /tmp/ FlashXXQ5VQQz και μάλιστα του έχει αντιστοιχίσει το file descriptor 11. Δηλαδή αν κοιτάξουμε στο /proc θα δούμε το εξής:

$ ls -l /proc/5035/fd/11

... 11 -> /tmp/FlashXXQ5VQQz (deleted)

Βρήκαμε το αρχείο μας, οπότε μπορούμε πλέον να εντυπωσιάσουμε το έτερό μας ήμισυ με το πώς μπορεί κάποιος να κάνει τα πάντα με τα ενσωματωμένα εργαλεία του Linux “αν είναι hacker”, δίνοντας απλά κάτι σαν το παρακάτω:

$ ffmpeg -vn -i /proc/5035/fd/11 nice_song.ogg

Αντίστοιχα αν έχουμε μερικά tabs / windows του firefox ανοιχτά με ένα τραγούδι στο κάθε tab και θέλουμε να τα μετατρέψουμε όλα μαζικά, τότε μπορούμε να χρησιμοποιήσουμε κάτι σαν το ακόλουθο script:

FILES=$(find /proc/*/fd/ -lname "/tmp/Flash*" 2>/dev/null)

for f in $FILES; do
  nm=${f##*/}; nm=${nm%% *};
  ffmpeg -vn -i $f ${nm}.ogg
done

Βλέπουμε ότι μπορούμε να βάλουμε τα fd κατευθείαν σαν είσοδο στο πρόγραμμα μετατροπής ffmpeg.
Για να πειραματιστείτε με αυτό το σενάριο στο συνοδευτικό qemu virtual machine τρέξτε: ./scenario1. Αυτό θα προσομειώσει τις ενέργειες του libflashplayer, ώστε να μπορείτε να δοκιμάσετε τις παραπάνω εντολές. Μπορείτε να ακούσετε το αποτέλεσμα με π.χ.,

sudo ogg123 6.ogg

Σενάριο 2: Ανάκτηση εκτελέσιμου malware

Ως μέρος του τακτικού ελέγχου σας σε ένα server ανακαλύπτετε ένα «περίεργο» εκτελέσιμο το οποίο φαίνεται να ονομάζεται “sh” (pid = 7083 εδώ) και το οποίο σας φαίνεται ότι κανονικά δε θα έπρεπε να υπάρχει στο output του ps:

$ ps aux | grep sh
pktoss 7083 ... sh

Ας πούμε ότι αποφασίζετε πριν «σκοτώσετε» την ύποπτη αυτή διεργασία (με kill -9
), να ανακτήσετε το εκτελέσιμο αρχείο της για ανάλυση. Ευτυχώς το εκτελέσιμο αρχείο μίας διεργασίας υπάρχει επίσης στο /proc, στο αρχείο /proc/
/exe. Καταρχήν ας σταματήσουμε το πρόγραμμα ώστε να μην μπορεί να κάνει περαιτέρω ζημιά:

$ kill -STOP 7083

Τώρα μπορούμε να ρίξουμε μια ματιά στα αρχεία στο /proc/
ώστε να μάθουμε περισσότερα:

$ readlink /proc/7083/exe
/home/frec/malware (deleted)

Φαίνεται ότι στην πραγματικότητα το εκτελέσιμό μας ξεκίνησε τη ζωή του ως /home/pktoss/malware και στη συνέχεια (κατά τη συνήθεια των προγραμμάτων αυτού του τύπου) αποσυνδέθηκε από το τερματικό που το δημιούργησε, άλλαξε το όνομά του και έσβησε τον εαυτό του από το δίσκο. Δεν υπάρχει όμως πρόβλημα για εμάς να το επαναφέρουμε:

$ cp /proc/7083/exe /home/pktoss/malware

Τώρα που ανακτήσαμε το εκτελέσιμο, μπορούμε να “παίξουμε” μαζί του. Σε αυτό το σημείο, ένας ειδικός της σήμανσης θα προσπαθούσε να το «αναστρέψει» δηλαδή να παράγει κώδικα πηγής (source code) ξεκινώντας από το εκτελέσιμο. Εμείς π.χ., μπορούμε απλά να τρέξουμε:

$ strings /home/pktoss/malware
[..]
username: 0xdead 
password: 0xbeef

Πολλές φορές κοιτώντας απλά τα στατικά strings σε ένα εκτελέσιμο μπορούμε να λάβουμε χρήσιμες πληροφορίες για τη λειτουργία του. Ίσως π.χ., το συγκεκριμμένο malware να συνδέεται πίσω σε κάποιο server του δημιουργού του χρησιμοποιώντας τα παραπάνω username και password. Το τι ακριβώς συμβαίνει θα το δείξει περαιτέρω ανάλυση η οποία είναι εκτός της εμβέλειας του παρόντος άρθρου. Όταν δε χρειαζόμαστε τη διεργασία του malware πλέον στη μνήμη, μπορούμε να την τερματίσουμε:

$ kill -9 7083

Είδαμε στα γρήγορα πώς η εμπειρία στην ανάκτηση αρχείων μπορεί να βοηθήσει και σε θέματα ασφάλειας. Φυσικά στις μέρες μας υπάρχουν πολύ πιο «εξελιγμένης νοημοσύνης» κακόβουλα προγράμματα στα οποία η παραπάνω τεχνική δεν είναι εφαρμόσιμη. Παρ' όλα αυτά, τα παραπάνω παραμένουν χρήσιμα απέναντι σε απλά στη λειτουργία τους κακόβουλα προγράμματα τα οποία κάθε άλλο παρά έχουν εκλείψει.

(Για να πειραματιστείτε με το σενάριο αυτό στην εικονική μηχανή δώστε ./scenario2. Αυτό θα δημιουργήσει ένα daemon process με τα παραπάνω χαρακτηριστικά, του οποίου το εκτελέσιμο μετά μπορείτε να ανακτήσετε από το /proc/
/exe. Ο κώδικας του εκτελέσιμου βρίσκεται στο αρχείο data/malware.c σε περίπτωση που θέλετε π.χ., να δείτε πώς γράφει κάποιος ένα πρόγραμμα σε C για Linux, το οποίο αλλάζει το όνομά του.

Σενάριο 3: Σώζοντας το download

Ας δούμε ένα λίγο πιο δύσκολο παράδειγμα, πώς κάνουμε ανάκτηση αρχείου στο οποίο γίνεται append, όπως για παράδειγμα ένα αρχείο που κατεβάζουμε στον υπολογιστή με την εντολή wget:

$ lsof | grep wget | grep deleted

wget ... /home/pktoss/myfile.iso (deleted)

Από ότι φαίνεται στο παράδειγμα, έχουμε σβήσει το αρχείο που κατεβάζει το wget. Αν το site από όπου κατεβάζουμε υποστηρίζει resume τότε δεν υπάρχει σοβαρό πρόβλημα. Απλά σταματάμε το wget με το σήμα STOP όπως είδαμε και παραπάνω, αντιγράφουμε το αρχείο από το /proc και μετά συνεχίζουμε το download με wget -c. Τι γίνεται όμως αν δεν υποστηρίζεται resume και δε θέλουμε και να ξαναρχίσουμε το download από την αρχή; Αντίστοιχη περίπτωση είναι όταν έχουμε σβήσει το log file ενός daemon αλλά δεν θέλουμε να τον σταματήσουμε για κάποιο διάστημα (μέχρι π.χ., να περάσουμε σε off-peak ώρες) ή όταν έχουμε ένα stream που γράφεται στο δίσκο μας, π.χ., από ένα PVR πρόγραμμα και δεν θέλουμε να το σταματήσουμε.

Ευτυχώς υπάρχει και γι αυτή την περίπτωση μία εύκολη και βολική (χωρίς ανάγκη να εγκαταστήσουμε τίποτα) λύση: θα χρησιμοποιήσουμε το πρόγραμμα tail για να ανανεώνουμε το copy του αρχείου συνεχώς μέχρι να σταματήσει να αλλάζει:

fname=$(find /proc/$(pidof wget)/fd/ -lname “*myfile.iso*”)
tail -c +0 -f $fname > ~/myfile.iso &

Όταν το append σταματήσει (π.χ., όταν το download ολοκληρωθεί) θα χρειαστεί φυσικά να τερματίσουμε το tail μόνοι μας.

Στην εικονική μηχανή, δώστε ./scenario3 (θα πάρει κάποια ώρα ανάλογα την ταχύτητα του υπολογιστή σας) και μετά μπορείτε να τρέξετε τις παραπάνω εντολές. Με tail -f wget-log μπορείτε να παρακολουθείτε την πορεία του “download” και όταν τελειώσει απλά δίνετε killall tail. Έπειτα μπορείτε να επαληθεύσετε την εγκυρότητα του myfile.iso είτε μέσω md5sum -c myfile.iso.md5 ή συγκρίνοντάς το με το αρχικό /tmp/myfile.iso. Για να ξέρετε πότε τελείωσε το download μπορείτε να τρέξετε

tail -f wget-log

Σενάριο 4: Ανάκτηση μεγάλου αρχείου ή αρχείου που αλλάζει με τυχαίο τρόπο

Μερικές φορές η μη σωστή χρήση των χαρακτηριστικών του shell όταν γράφουμε scripts μπορεί να οδηγήσει σε ασύμμετρα μεγάλους μπελάδες. Έτσι και αυτή τη φορά, η μη χρήση του “set -u” από ένα junior admin σε συνδυασμό με ένα μικρό typo στο όνομα μιας μεταβλητής περιβάλλοντος είχε ως συνέπεια αντί για ένα προσωρινό αρχείο, να σβηστεί το innodb tablespace μιας μεγάλης εγκατάστασης MySQL (άουτς!). Το κακό με τα αρχεία του tablespace είναι ότι συγκεντρώνουν τα δεδομένα από όλες τις βάσεις οπότε αν σβηστούν χάνουμε όλες τις βάσεις του server ταυτόχρονα (ξανά άουτς!). Επίσης πολλές φορές τέτοια αρχεία (άλλη όμοια περίπτωση είναι το disk image ενός virtual machine) είναι υπερβολικά μεγάλα για να αντιγραφούν (μπορεί να μην υπάρχει καν χώρος) και αν δε θέλουμε/μπορούμε να σταματήσουμε το server τότε υπάρχει και το θέμα ότι το αρχείο ανανεώνεται με «τυχαίο» τρόπο (δήλ. όχι αναγκαστικά append), άρα το cp δε θα μας δώσει κατ' ανάγκη τα τελευταία δεδομένα, ίσως ούτε καν ένα έγκυρο αρχείο!

Η μόνη λύση είναι να επέμβουμε σε επίπεδο πυρήνα / VFS και να «επαναφέρουμε το χαμένο hard-link». Με αυτό τον τρόπο επαναχρησιμοποιούμε το ίδιο inode και data blocks οπότε ούτε έχουμε επιβάρυνση σε χώρο, ούτε χάνονται οι αλλαγές στο αρχείο. Για να γίνει όμως αυτό χρειάζεται να μας βοηθήσει ο ίδιος ο πυρήνας. Η πρώτη ιδέα ήταν να γραφτεί αυτή η λειτουργικότητα σαν system call (flink) κάτι που δεν «περπάτησε» όμως, λόγω των προβλημάτων ασφάλειας [1] που θα δημιουργούσε ένα τέτοιο system call.

Έτσι, ο μοναδικός τρόπος υλοποίησης αυτής της λειτουργικότητας είναι πιθανότατα μέσω ενός loadable module το οποίο θα ελέγχεται από το userspace μέσω ioctl. Μία τέτοια λύση είναι το frelink [2]. Ας δοκιμάσουμε ένα τέτοιο σενάριο ανάκτησης μέσω frelink στη συνοδευτική εικονική μηχανή: Τρέξτε το script ./scenario4. Αυτό θα χωρίσει την οθόνη στα 2 (μέσω screen) και στο πάνω μέρος θα κατασκευάσει 300 mysql πανομοιότυπα innodb databases (ώστε να παραχθεί ένα ικανοποιητικού μεγέθους tablespace file).

Μόλις οι βάσεις κατασκευαστούν, το script θα σβήσει το tablespace file (ibdata1) και μετά θα αρχίσει να χρησιμοποιεί τις βάσεις διαβάζοντας και γράφοντας σε μία τυχαία βάση κάθε λίγο. Αυτό παρέχει ένα έστω κι ελάχιστα ρεαλιστικό μοντέλο λειτουργίας ενός server.

Θα χρησιμοποιήσουμε το frelink για την ανάκτηση, ως εξής (βλ. και σχετικό screenshot)

cd frelink
make &>/dev/null
sudo insmod frelink.ko
FD=$(sudo find /proc/*/fd -lname “*ibdata1*” 2>/dev/null)
sudo ./frelink $FD

Βλέπουμε ότι το frelink κατάφερε να ανακτήσει το αρχείο ibdata1 και η βάση συνεχίζει να λειτουργεί κανονικά μετά από restart.

Σενάριο 5: Ανάκτηση loop-mounted αρχείου

Στην περίπτωση loop-mounted αρχείου τα πράγματα είναι ακόμα πιο δύσκολα εφόσον και να θέλαμε δεν υπάρχει κάποιο fd στο /proc από το οποίο να μπορούμε να αντιγράψουμε. Έτσι το frelink αναγκάζεται να χρησιμοποιήσει ένα κάπως «διαβολικό» κόλπο, εκμεταλλευόμενο το γεγονός ότι το module που διαχειρίζεται το loop device, διατηρεί το struct file * του αρχείου στην ιδιωτική του μνήμη. Έτσι, αυτό που κάνει το frelink είναι να “κλέψει” αυτή την πληροφορία από εκεί και στη συνέχεια να χρησιμοποιήσει την πληροφορία που “έκλεψε” για να επαναφέρει το αρχείο με τον ίδιο τρόπο που χρησιμοποιεί και για τα ανοιχτά αρχεία. Λόγω αυτού του “κόλπου”, το frelink μπορεί να είναι αρκετά «εύθραυστο» αν ο χρήστης επιχειρήσει κάτι περίεργο κατά τη διάρκεια της ανάκτησης, όπως π.χ., να μετακινήσει το loop device σε άλλο αρχείο ή κάτι τέτοιο (κάτι που βέβαια οι περισσότεροι δε θα έκαναν έτσι κι αλλιώς).

Για να πειραματιστούμε με την ανάκτηση loop-mounted αρχείου (από «φρέσκο» VM και αφού πρώτα τρέξουμε το ./scenario5) κάνουμε τα εξής:

cd frelink
make &>/dev/null
sudo insmod frelink.ko
DEV=$(sudo losetup -a | grep myfs.img | sed 's/:.*//')
sudo ./frelink $DEV

Βλέπουμε ότι το myfs.img επανήλθε στο /home/frec και συνεχίζει να υπάρχει ακόμα και αν κάνουμε unmount το tmp/

Επίλογος

Στο πρώτο επεισόδιο αυτής της σειράς άρθρων, είδαμε σενάρια και τεχνικές ανάκτησης ανοιχτών και loop-mounted αρχείων. Καλύψαμε τόσο περιπτώσεις που λύνονται με τα ήδη υπάρχοντα εργαλεία μιας διανομής, όσο και περιπτώσεις για τις οποίες χρειάζεται μεγαλύτερο sophistication, που επιτυχγάνεται μέσω του συστήματος frelink. Για τις περιπτώσεις που δεν υπάρχει άλλη λύση από το frelink, θα πρέπει να είμαστε πολύ προσεκτικοί στη χρήση του και να το έχουμε δοκιμάσει σε πανομοιότυπο πυρήνα πριν το χρησιμοποιήσουμε σε μηχάνημα “παραγωγής”. Επίσης αν υπάρχει η δυνατότητα να προχωρήσουμε σε επανεκκίνηση λίγο αφότου βεβαιωθούμε ότι η ανάκτηση έχει γίνει σωστά, αυτό θα σιγουρέψει ότι οι εσωτερικές δομές του VFS είναι σε καλή κατάσταση. Αν το frelink αποδειχθεί χρήσιμο, μπορεί εξάλλου να βελτιωθεί προσθέτοντας χαρακτηριστικά στον «κυρίως» πυρήνα. Ο γράφων θα χαρεί να απαντήσει σε σχόλια ή απορίες.

[1] flink συζήτηση στην lkml http://goo.gl/EAVMt
[2] frelink https://github.com/pkt/frelink

Ο Παντελής ασχολείται με το Linux administration και τον προγραμματισμό.