Tag Archives: performance
Migrating from Python 2 to Python 3

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")

Continue Reading →

XFS corruption – repairing

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.

Continue Reading →

When there’s no route forward (or so you fear)

Note: This is a text about the project work at one of my previous employments.

Introduction

These days everybody talks about Agile, Automation, DevOps and Continous (whatever), without truly understanding why things have gone in this direction. After all, for many years, a software project had a couple of well-known steps that needed to be followed, like:

  • Full, thorough planning at the very beginning and from time to time, before significant milestones;

  • Development, lots of development behind closed doors;

  • Lots of manual QA work, little automation with some custom-written testing framework written from scratch by one of the developers;

  • Infrequent releases (e.g. every year or even every other year or so); releases were thoroughly prepared and tested, with code freezes for (sometimes) months before the Day.

Even if everybody knows these days that such approach may have been a bad way of doing things, it actually worked for many years because that was the way the world expected things to work. There were many constraints, e.g:

Continue Reading →

Next Page