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? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
