Wang,
Futher, a easy way to trigger this problem is by running the following
c codes repeatedly:
int main(int argc, char **argv)
{
/* pass a btrfs block device */
int fd = open(argv[1], O_RDWR | O_EXCL);
if (fd < 0) {
perror("fail to open: %s", strerror(errno));
exit(1);
}
close(fd);
return 0;
}
So the problem is RW opening would trigger udev event which will
call btrfs_scan_one_device().
In btrfs_scan_one_device(), it
would open the block device with EXCL flag..meanwhile if another
program try to open that device with O_EXCL, it would fail with
EBUSY.
Expected. But do we need O_EXCL in kernel:btrfs_scan_one_device()
at all ?
This happen seldomly in the real world, but if we use loop device
for test, we may hit this annoying problem.
A walkaround way to solve this problem is to wait kernel scanning
finished and then try it again.
I agree this happens seldom in production. But I don't agree on
something to fix as workaround.
Just sent out the patch:
btrfs: looping mkfs.btrfs -f <dev> may fail with EBUSY
which I believe can be a final fix. Your review / tests appreciated.
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
