@antirez,
Now that we have preamble AOF file enabled by default, it affects AOF rewrites, and cases where appendonly config is set at runtime (causing a fork an a rewrite), but there's one case where we still create simple AOF files, which is when the server starts up configured with appendonly and has no pre-existing AOF file on the disk.
There are at least few obvious disadvantages of a simple AOF: 1. the preamble rdb has some metadata about the server that created it and so on, that we're missing in the simple AOF. 2. it's a bit odd that some AOF files look different than others in their format. i can imagine a case where someone writes a piece of code that processes AOF files, and tests it only one one case, getting a surprise bug later on when he unexpectedly encounters the other type. 3. in the rdb, modules can inject some out of keyspace aux data, they may need / want that ability also in freshly created AOF files. some modules may depend on that ability (obviously assuming the module was loaded at startup).
In theory, it should be quite simple to dump an empty RDB file header into the AOF file when creating it on server startup (probably without a fork)
Comment From: silvpol
@oranagra
Simple aof file has one very useful feature - you can easily copy it somewhere else and then to re-import cat file | redis-cli --pipe. Currently redis-cli chokes on the new mixed format.
Comment From: yossigo
Hi @silvpol, this could actually be a nice redis-cli feature: the ability to load the RDB preamble (as a sequence of RESTORE commands or whatever). It would be much faster as well.
Comment From: oranagra
the preamble on creation part was handled by https://github.com/redis/redis/pull/9788 the one about redis-cli mass insertion from rdb, is tracked in https://github.com/redis/redis/issues/9717