Comment # 12 on bug 1068647 from Martin Wilck

I think I've understood what's going on. 

During startup of gdm, there seems to be a race for the filr
/var/lib/gdb/.config/dconf/user. Various gsd-related daemons open and mmap()
this file, while at the same time the "dconf-service" utility replaces it
(twice) with a different file using rename() system calls. The gsd daemons keep
the mapping of the old, deleted file in memory, which causes the file to become
an orphan. As soon as gdm is stopped, the orphan disappears. This explains the
observations made in comment 10 and comment 11.

I can see two problems here:

 1) the behavior of the gnome-settings-daemon seems to be badly in line with
what "dconf-service" is doing. Upon closer inspection, I can see lots of
processes mapping deleted instances of /run/user/$UID/dconf/user and
$HOME/.config/dconf/user, for both the gdm account and my account. The btrfs
send problem aside, that can't be a healthy situation, but it has to be either
a dconf or a gsd problem, or both.

 2) Nonetheless, it's commonplace that processes have open fds or mmaps for
deleted files. It seems wrong that "btrfs send" would fail in such situations.
The right thing (TM) to do for orphan inodes in this specific case (callstack
in comment 1) would be to ignore the orphan for the send_utimes call.

I'm going to split off (1) from this bz. For (2), I may come up with a btrfs
patch.