al posted on Tue, 17 May 2016 01:40:19 +0000 as excerpted: > I'm still getting this regression on scrub. Scrub status no longer > reports the progress of the scrub. It always used to. > > The scrub itself proceeds normally and using '-B' returns the usual and > complete output. > > # btrfs scrub start / > scrub started on /, fsid fdd6a335-6edf-4a74-a909-03c8102cc8f5 (pid=4111) > > <reasonable time passes> > > # btrfs scrub status / > scrub status for fdd6a335-6edf-4a74-a909-03c8102cc8f5 > no stats available total bytes scrubbed: 0.00B with 0 errors
That's almost certainly due to the state of the location where btrfs stores scrub status information, /var/lib/btrfs, which should be a directory that's both writable by btrfs during the scrub, and readable at the time btrfs scrub status is run. It appears that (as expected for such commands) you're running btrfs as root, so normal file permissions shouldn't matter. However, if you have that filesystem mounted read-only at the time, or if you or your distro has configured additional security restrictions like SE Linux and they're preventing access to that dir, that would explain the problem. Additionally, I'm not sure whether btrfs scrub will create that directory (and its parents /var/lib and /var) dynamically if needed, or if the package is supposed to do that at installation, so btrfs scrub itself doesn't do it. In the latter case, if the directory simply doesn't exist, that would prevent the status files from being written, and thus read, as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
