On Thu, Jan 15, 2015 at 10:02:37AM -0800, Zach Brown wrote:
It says that scrub isn't running if any devices have completed. If you
drop
all those ret 0 conditional branches that are either noops or wrong,
does it
work like you'd expect?
Why wrong? The ioctl callback returns
On Thu, Jan 15, 2015 at 12:24:41PM +0100, David Sterba wrote:
On Wed, Jan 14, 2015 at 02:27:17PM -0800, Zach Brown wrote:
On Wed, Jan 14, 2015 at 04:06:02PM -0500, Sandy McArthur Jr wrote:
Sometimes btrfs scrub status reports that is not running when it still is.
I think this a
On Wed, Jan 14, 2015 at 02:27:17PM -0800, Zach Brown wrote:
On Wed, Jan 14, 2015 at 04:06:02PM -0500, Sandy McArthur Jr wrote:
Sometimes btrfs scrub status reports that is not running when it still is.
I think this a cosmetic bug. And I believe this is related to the
scrub completing on
Am Wed, 14 Jan 2015 16:06:02 -0500
schrieb Sandy McArthur Jr sandy...@gmail.com:
Sometimes btrfs scrub status reports that is not running when it still is.
[...]
FWIW, I (and one other person) reported this in the thread titled 'btrfs scrub
status misreports as interrupted' (starting on
Okay, different output when the scrub is actually complete:
completed status:
scrub status for 94b3345e-2589-423c-a228-d569bf94ab58
scrub started at Tue Jan 13 01:18:22 2015 and finished after 139459 seconds
total bytes scrubbed: 23.30TiB with 513 errors
error details: verify=19 csum=494
Sometimes btrfs scrub status reports that is not running when it still is.
I think this a cosmetic bug. And I believe this is related to the
scrub completing on some drives before others in a multi-drive btrfs
filesystem that is not well balanced.
Based on `iostat 1` activity the last drive in
On Wed, Jan 14, 2015 at 04:06:02PM -0500, Sandy McArthur Jr wrote:
Sometimes btrfs scrub status reports that is not running when it still is.
I think this a cosmetic bug. And I believe this is related to the
scrub completing on some drives before others in a multi-drive btrfs
filesystem that
