As the world evolves, one may want to take on new opportunities to get better things out of the door, e.g. use the “new” async paradigm or make better use of generators and iterators. This means using Python 3 – and this also usually means migrating large codebases from Python 2. Sometimes this is as easy as flipping the bit, other times it may be better to just refactor the whole code. Let me point out some differences, though.
1. print
This one is easy – most of the time it’s just about translating code from:
print "abcd"
to:
print("abcd")
You don’t get to explicitly use Linux namespaces very often; one usually gets to make use of them when setting up containers or some sort of smart web hosting platform that allows hard resource limits to be put in place for customers, but even then the actual setup is hidden somewhere in the back. There are scenarios when containers simply require too much work for the particular task; I, at one time, faced the need of ensuring some network communication between 2 instances of the same service.
Communication? Same service? Have them listen on different addresses or on different ports and you’re done, you might say – but it’s not always that simple. If you have no control over the code but just want to replicate a certain behavior, there may simply not be an option to have instances listen on different ports. If the protocol also involves broadcasting, things become really complicated, as you don’t always have 2 IP addresses, on different interfaces, connected to the same network. Such scenario is easy to solve with virtualization or containers, but for this particular problem they’re overkill. The lightweight solution comes from manipulating Linux network namespaces.
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.