* Scrub status regression (repost kinda)
@ 2016-05-17 1:40 al
2016-05-17 6:39 ` Duncan
0 siblings, 1 reply; 3+ messages in thread
From: al @ 2016-05-17 1:40 UTC (permalink / raw)
To: linux-btrfs
Hi All,
I'm still getting this regression on scrub. Scrub status no longer reports
the progress of the scrub. It always used to.
Anyone else experiencing the same regression?
Only quirky part of my setup which may throw btrfs off is that I create and
mount the first subvol as the root of the install. I repeat it is only
recently 3m that it has started to cease reporting.
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Scrub status regression (repost kinda)
2016-05-17 1:40 Scrub status regression (repost kinda) al
@ 2016-05-17 6:39 ` Duncan
2016-05-17 20:30 ` [SOLVED] " al
0 siblings, 1 reply; 3+ messages in thread
From: Duncan @ 2016-05-17 6:39 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [SOLVED] Re: Scrub status regression (repost kinda)
2016-05-17 6:39 ` Duncan
@ 2016-05-17 20:30 ` al
0 siblings, 0 replies; 3+ messages in thread
From: al @ 2016-05-17 20:30 UTC (permalink / raw)
To: linux-btrfs
Duncan <1i5t5.duncan <at> cox.net> writes:
> 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.
Thank you, sir, for taking the time to post at length.
The (need to) repost gives it away as something I'd done/not done; rather
than a generic problem.
I think I've always run some btrfs commands as root, because they've not
allowed themselves to run with lower priv. It sounds to me like I have
hamstrung myself somewhere/somewhat as the directory is only for root user
(only).
$ la /var/lib/btrfs
total 8.0K
-rw------- 1 root root 360 Jan 26 11:45
scrub.status.caf3bccc-6061-44bc-9726-96a87cfdb9eb
-rw------- 1 root root 1.4K May 17 02:12
scrub.status.fdd6a335-6edf-4a74-a909-03c8102cc8f5
The two files represent two file systems scrubbed (a RAID6 4device and a DUP
single). Both are effectively 'zero'.
So it only remains to go find the directory correct permissions and if the
directory is recreated. I'll come crying back if I can't find it!
Been running btrfs from quite early on, early linux three I think, and have
only had it self-implode once. Every other problem has been of my own making
I think: damn you 'dd'.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-05-17 20:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-17 1:40 Scrub status regression (repost kinda) al
2016-05-17 6:39 ` Duncan
2016-05-17 20:30 ` [SOLVED] " al
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).