Note: The “magical” tool for XFS is (obviously) xfs_repair. Having it running can sometimes be the tough issue.
Introduction
How could a filesystem corruption happen? There are a couple of likely causes to it:
Kernel bugs: they are infrequent but they also did happen many times in the past and will still happen in the future. Not many things to be done about them, other than applying patches / keeping the kernel up to date;
Memory issues, e.g. memory errors propagated to the file system in control structures: they are usually mitigated with ECC memory but they can never be ruled out;
Underlying storage issues: quite unlikely but nevertheless possible;
Using the reset button on running servers: journaling file systems are almost always able to recover from such incident;
RAID controller issues: this could be the leading cause and not be easy to mitigate, even if firmware upgrade is sometimes possible.
The long interview day is nearing its end. Googamazbook got the best and the worst out of you (well, neither of those, but I’m trying to put some literature in here); the last interviewer comes in, smiles condescendently and greets you with:
Time for the easy interview, heh?
Yes, you have all the reasons to be concerned and feel you’re just one step away from failure (yes, why didn’t you spend the day by the pool in the basement of the many stars hotel they got you a room in for the interview?). But without further ado, the questions start pouring in:
Question 1
How do you figure out if a process is CPU bound or I/O bound?
Tricky! Let’s not jump to the conclusion. There are 2 variables here, this means we have 4 possibilities:
You’re in a tiny room at Googamazbook and the interviewer comes in, says hi (if you’re lucky), presents themselves (they’re really into doing you a favor) and then starts asking questions. The easy one comes first:
What happens when you run telnet www.brainware.ro 80 ? Please go on through all the layers.
Warmed up from the systems interview, you start talking about /etc/hosts and /etc/resolv.conf: name resolution and then the actual connection to the http port. If your knowledge stops here, please do go on reading this text. Or just do go on, maybe I forgot something.
1. Name Resolution
The name resolution protocol is performed by sending an UDP packet to each resolver found in /etc/resolv.conf. The UDP packet has a small header containing: