btrfs: stripe_alloc: say at mount whether the policy is on
Two paths turn stripe-exclusive allocation on and neither announced it.
The mount option sets the flag while btrfs_emit_options() has no entry to
print for it, and the btrfs.stripe_alloc property applies later still,
when btrfs_fill_super() reads the root directory's inode and its
properties. btrfs_enable_stripe_alloc() did print a line, but only on
the property path, and even there it is skipped when the option already
set the flag, because the function returns early in that case.
So the log said nothing. An absent line meant "off" and "on via the
mount option" equally well, and the only way to answer the question was
to read /proc/mounts on a live filesystem -- no use when the filesystem
is someone else's, or when all that is left is a log from before a crash.
Analysing a lockup from a filesystem whose btrfs.stripe_alloc property
was set, I read that silence as the policy being off and said so, which
was wrong twice over: the property was set, and the option would have
been just as invisible.
State it once in btrfs_fill_super(), after the root inode has been read
so the property has had its say, naming which of the two turned it on.
The option is sampled before open_ctree(), not merely before that read:
the mount context has already reached fs_info by the time
btrfs_fill_super() runs, and open_ctree() itself goes far enough into the
mount to read the root directory's inode and apply the property, so a
sample taken after it reports every property-enabled filesystem as an
option-enabled one. The directed test caught exactly that. A remount that changes the flag reports the
change as well. The property path keeps its own line for a set on a live
filesystem, where there is no mount to report; at mount it now stays
quiet so the line is not printed twice.
Nothing is printed when the policy is off, which keeps the common mount
quiet and makes the absence of the line mean exactly one thing.
projects / linux / commit