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.
--
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
