>> The gotcha though is there's a pile of data in the journal >> that would never make it to rsyslogd. If you use journalctl >> -o verbose you can see some of this.
> You can send *all the info* to rsyslogd via imjournal > http://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html > In my setup all the data are stored in json format in the > /var/log/cee.log file: > $ head /var/log/cee.log 2017-04-28T18:41:41.931273+02:00 > venice liblogging-stdlog: @cee: { "PRIORITY": "6", "_BOOT_ID": > "a86d74bab91f44dc974c76aceb97141f", "_MACHINE_ID": [ ... ] Ahhhhhh the horror the horror, I will never be able to unsee that. The UNIX way of doing things is truly dead. >> The same behavior happens with NTFS in qcow2 files. They >> quickly end up with 100,000+ extents unless set nocow. >> It's like the worst case scenario. In a particularly demented setup I had to decastrophize with great pain a Zimbra QCOW2 disk image (XFS on NFS on XFS on RAID6) containining an ever growing number Maildir email archive ended up with over a million widely scattered microextents: http://www.sabi.co.uk/blog/1101Jan.html?110116#110116 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
