Re: [PATCH v3 0/3] btrfs: Make balance cancelling response faster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/02/2020 06:16, Qu Wenruo wrote:
...
> [FIX]
> This patchset will add more cancelling check points, to make cancelling
> faster.

I have a question on what this means for users of the balance ioctl.

I *think* that, today, there is a guarantee that if I issue the ioctl to
start a balance, and then immediately (or, some time later) cancel it, I
will be guaranteed that at least one block group will be balanced. In
particular, if I repeat that behaviour, the balance will eventually
complete.

Is that true?

If so, what happens to this guarantee with these changes?

I think, from your description, that the cancel can complete without
even one block group being balanced. Is it guaranteed to have made
progress on that bg so that if I repeat the behaviour that bg (and
eventually all eligible bgs) will be balanced? Or is it now possible to
cancel before any progress has been made sp that process never finishes?

If the latter, how long do I have to wait before cancelling to make sure
that progress has been made? Is there any way to know whether progress
has been made when the ioctl completes with the cancelled status?

This is a real question because I have some filesystems where balancing
a single block group can sometimes take tens of minutes, and the system
is impacted during that time. I already have my btrfs-balance-slowly
script which allows me to control impact by not trying to balance the
next bg for a while, so the system can recover and progress other tasks.
And it would be great to be able to limit the impact further by
cancelling during a single bg, but only if I can be sure that progress
has been made and that by repeating the process I am guaranteed that it
will eventually finish.

In any case, I suggest that the patch cover letter (and maybe code
comments) explains what guarantees (if any) userspace is given.

Graham



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux