On Tue, Feb 18, 2014 at 08:05:12PM +0000, Kevin Chadwick wrote: > It's just occurred to me that the binary format may not work with append > only logging?
That's true for the journal. When the journal opens its binary log, it flags the file as being opened, but what is the issue with not being append only? > Also recovering those logs from a possibly intentionally > uncompletely wiped disk would be much harder especially on an ext3/ext4 > filesystem where carving is required when otherwise you could image or > ddrescue in case of hardware failure and use grep. I have not tried, but I imagine it not being that much harder for the following reasons: If your journal is compressed, you basically lose, but that is true for compressed text logs as well. So if you need this recovery scenario, don't compress. If your journal is uncompressed, you can exploit aspects of the format to find the log. Specifically, log entry consists of key-value pairs, most of which likely match /\(_SYSTEMD_[A-Z_]*\|MESSAGE\)=.*/. Another technique would be to watch out for 8byte aligned object headers, which are fairly unique as well. (The latter should also work with compression enabled.) So identifying what parts of your filesystem are covered with journal logs should be relatively easy even without knowledge of the underlying filesystem (unless it compresses on its own as btrfs can do). I am not aware of any recovery tool yet, but given the number of systems already deployed with the journal, some early adopters will come around creating it way before Debian is going to make the journal persistent. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140219043231.ga18...@alf.mars
