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 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.
> >
> > Boy, I don't really know this code, but it looks like:
> >
> > if (ss->in_progress)
> > printf(", running for %llu seconds\n", ss->duration);
> > else
> > printf(", interrupted after %llu seconds, not running\n",
> > ss->duration);
> >
> > in_progress = is_scrub_running_in_kernel(fdmnt, di_args,
> > fi_args.num_devices);
> >
> > static int is_scrub_running_in_kernel(int fd,
> > struct btrfs_ioctl_dev_info_args *di_args, u64 max_devices)
> > {
> > struct scrub_progress sp;
> > int i;
> > int ret;
> >
> > for (i = 0; i < max_devices; i++) {
> > memset(&sp, 0, sizeof(sp));
> > sp.scrub_args.devid = di_args[i].devid;
> > ret = ioctl(fd, BTRFS_IOC_SCRUB_PROGRESS, &sp.scrub_args);
> > if (ret < 0 && errno == ENODEV)
> > continue;
> > if (ret < 0 && errno == ENOTCONN)
> > return 0;
> >
> > 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 -ENODEV or -ENOTCONN that get
> translated to the errno values and ioctl(...) returns -1 in both cases.
Wrong because returning 0 on the first ENOTCONN, instead of continuing
to find more devices which might still be scrubbing, leads to this
confusing status message.
That's my working theory having spent 15 seconds reading code. I would
be not surprised at all if I'm missing something here.
- z
--
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
