On Tue, Jan 24, 2017 at 01:48:12PM -0700, Chris Murphy wrote: > journal_debug.log booted with patched kernel and params > systemd.log_level=debug rd.debug, and then output to file with > journalctl -b -o short-monotonic > https://drive.google.com/open?id=0B_2Asp8DGjJ9MjRDWi0tZ0x4V2s > > I'm uncertain of the immediacy of some event resulting in another but... > > > [ 8.159581] f25h systemd-tmpfiles[720]: Running create action for > entry d /var/run/pptp > [ 8.159703] f25h systemd-tmpfiles[720]: Created directory "/var/run/pptp". > [ 8.159825] f25h systemd-tmpfiles[720]: "/var/run/pptp" has right mode > 40750 > [ 8.159944] f25h systemd-tmpfiles[720]: Running remove action for > entry d /var/run/pptp > [ 8.160070] f25h systemd-tmpfiles[720]: Running create action for > entry d /var/run/radvd > [ 8.160186] f25h systemd-tmpfiles[720]: Created directory "/var/run/radvd". > [ 8.160312] f25h systemd-tmpfiles[720]: "/var/run/radvd" has right mode > 40755 > [ 8.171770] f25h kernel: ------------[ cut here ]------------ > [ 8.174028] f25h kernel: WARNING: CPU: 2 PID: 720 at > fs/btrfs/delayed-inode.c:55 > btrfs_get_or_create_delayed_node+0x16a/0x1e0 [btrfs] > [ 8.176316] f25h kernel: ino 2 is out of range > > > Is it the creation of these directories triggering the error? Anyway, > there's a bunch of systemd-tmpfiles activity prior to this, and right > before the btrfs_get_or_create_delayed_node call trace. > > > The final call trace is cut off, I guess when systemd switches from > /run to /var and flushes, if the fs goes read only and can't write all > of what's flushed, it results in journal data loss. If the rest of the > output is useful I can switch systemd to only use volatile storage to > avoid this problem.
Got this to repro after installing systemd-container. It's happening on lsetxattr() to set the SELinux context on /var/lib/machines, which is a subvolume. Looking into it now. Thanks for all of the help, Chris. -- 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
