Thanks for more comments, Konstantin. I have implemented your suggestions and also some other modifications due to some observations that Luca made offline. Luca pointed out that the way open() was implemented in the previous version of the patch, it was not very flexible and it would prevent us from having open methods to other types of log devices because it was taking a parameter specific to a file.
I have instead moved the parameter that configures the output buffer size to FSEditLog (FSEditLog::sizeOutputFlushBuffer), and now the calls in FSEditLog that currently create an output log stream (EditLogFileOutputStream) use FSEditLog::sizeOutputFlushBuffer when calling the constructor of EditLogFileOutputStream. To set the value of FSEditLog::sizeOutputFlushBuffer, there is a method called setOutputFlushBuffer(int). Note that FSEditLog::sizeOutputFlushBuffer is not static as before. I prefer to have an instance attribute instead of a static one to avoid confusion when instantiating multiple times the same class.
I also think that FSEditLog is currently the right place to keep the configuration of log devices because FSEditoLog contains calls to start and stop such devices. However, I would like to propose a different solution for configuring log devices (not for this patch, though). We should have a class, called perhaps EditLogDevConfig, that holds all the parameters necessary for the log devices a particular instance of the namenode requires. When calling the constructor of a particular log stream device, we just pass such a configuration parameter and the constructor takes care of extracting the necessary parameters.