Re: [PATCH 0/5] Add trace events for filesystem freeze/thaw events

From: Al Viro <viro@ZenIV.linux.org.uk>
To: Frank Sorenson <sorenson@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, dwysocha@redhat.com, lvaz@redhat.com
Subject: Re: [PATCH 0/5] Add trace events for filesystem freeze/thaw events
Date: Wed, 2 Mar 2016 21:47:44 +0000	[thread overview]
Message-ID: <20160302214744.GN17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1456945319-16283-1-git-send-email-sorenson@redhat.com>

On Wed, Mar 02, 2016 at 01:01:54PM -0600, Frank Sorenson wrote:
> Currently, the only visibility into filesystem freeze or
> thaw activity is when an error is returned from the actual
> call to freeze or thaw.  If the action itself hangs, there
> is no indication that the freeze or thaw was in-progress,
> short of collecting a vmcore.
> 
> There is also no record of what process froze a filesystem
> or when it happened, so if the process does not thaw it
> later, debugging the issue is difficult.
> 
> These patches add tracepoints to the generic filesystem
> freeze and thaw functions.  When enabled, trace events
> will create a record of these activities.

Let's provide a sane stable ABI for the things it's going to be
used for.  Because _this_ is very likely to end up with
"something needs to keep track of those events boot-to-shutdown" ->
"something in systemd guts will be keeping track of those and
broadcasting the collected information on state over dbus for the
rest of dbus-infested system to see" -> "touch any details and you
break real userland code" -> "it's cast in stone forever".  With
systemd folks not particularly happy about the details, but even
less happy about the need to make the already grotty code parsing
those depend on the kernel version.

And as much as I don't like Lennart et.al., in this case they would
be perfectly justified.  Information in question is potentially interesting,
due to the form it is presented in one really needs to keep track of all
messages since boot to make any use of it and it's clearly a job for
a long-running daemon to collect those - nothing else would be able to.
And once such a daemon starts using that, its authors would have very good
reasons to demand the fucking ABI to be fucking stable.  After all, they
weren't the ones who came up with the nasty details we might want to change.

So let's get it right.  Preferably - without need for boot-to-shutdown
tracking just to mirror the state.  What do we really want?

* an ioctl to query the state (frozen/freezing/not frozen) for something in
util-linux to use?

* /proc/fs/freezing and /proc/fs/frozen, with ->s_id of affected filesystems
or, pehaps, one file with (frozen|freezing) + ->s_id?

* ability to audit on state changes?  That'd need some thought re what to
do when some joker freezes the fs syslogd is logging to...

* something else entirely?