Recent Features
| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 21, 2011 14:22 UTC (Mon) by nix (subscriber, #2304)In reply to: The Journal - a proposed syslog replacement by jubal Parent article: The Journal - a proposed syslog replacement
Quite. I have repeatedly in the past been able to get a lot of useful info from logs damaged by disk or fs damage. Sure, a few blocks were full of \0s or just plain garbage --- but the rest was readable. Who cares if the file as a whole no longer conforms to any formal grammar? Human beings don't need one!
But computers do. A binary->text tool would probably have given up in the face of such damage. At best it would go down a rarely-used hence buggy parser-error-recovery code path.
(Log in to post comments)
This depends on the design, actually Posted Nov 21, 2011 18:27 UTC (Mon) by khim (subscriber, #9252) [Link] But computers do. A binary->text tool would probably have given up in the face of such damage. At best it would go down a rarely-used hence buggy parser-error-recovery code path. Computers do what they are programmed to do. If you'll write program which tolerates corrupt files then it'll just that. It's not as hard to do as you think: you don't need cryptohash for that, CRC32 is enough and it's exteremely fast novadays. But sure, you must plan for that in advance. This is what Google does with it's petabytes of logs - works fine from what I've heard.
|
|||||||||||||