| Message ID | afdb0e99249c050b26a200ccbbc772a1ef90c1a4.1522780026.git.dsterba@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 04/04/2018 02:34 AM, David Sterba wrote: > Balance cannot be started on a read-only filesystem and will have to > finish/exit before eg. going to read-only via remount. Cancelling does > not need to check for that. > > In case the filesystem is forcibly set to read-only after an error, > balance will finish anyway and if the cancel call is too fast it will > just wait for that to happen. Again does not have to check. What if there is a power recycle and mounted as readonly after the reboot? Thanks, Anand > Signed-off-by: David Sterba <dsterba@suse.com> > --- > fs/btrfs/volumes.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index a0420af1fad9..2956e7b4cb9f 100644 > --- a/fs/btrfs/volumes.c > +++ b/fs/btrfs/volumes.c > @@ -4053,9 +4053,6 @@ int btrfs_pause_balance(struct btrfs_fs_info *fs_info) > > int btrfs_cancel_balance(struct btrfs_fs_info *fs_info) > { > - if (sb_rdonly(fs_info->sb)) > - return -EROFS; > - > mutex_lock(&fs_info->balance_mutex); > if (!fs_info->balance_ctl) { > mutex_unlock(&fs_info->balance_mutex); > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 16, 2018 at 05:43:46PM +0800, Anand Jain wrote: > On 04/04/2018 02:34 AM, David Sterba wrote: > > Balance cannot be started on a read-only filesystem and will have to > > finish/exit before eg. going to read-only via remount. Cancelling does > > not need to check for that. > > > > In case the filesystem is forcibly set to read-only after an error, > > balance will finish anyway and if the cancel call is too fast it will > > just wait for that to happen. Again does not have to check. > > What if there is a power recycle and mounted as readonly > after the reboot? So the balance item would be stored on disk from previous run, mount will set it up but balance will not be resumed (sb_rdonly check in open_ctree happens earlier). Calling btrfs_cancel_balance by ioctl would reset the in-memory state and also would want to delete the balance item on disk, so yes, the check is needed. I'll add a comment explaining why the read-only check is there instead. Thanks for catching it. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index a0420af1fad9..2956e7b4cb9f 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4053,9 +4053,6 @@ int btrfs_pause_balance(struct btrfs_fs_info *fs_info) int btrfs_cancel_balance(struct btrfs_fs_info *fs_info) { - if (sb_rdonly(fs_info->sb)) - return -EROFS; - mutex_lock(&fs_info->balance_mutex); if (!fs_info->balance_ctl) { mutex_unlock(&fs_info->balance_mutex);
Balance cannot be started on a read-only filesystem and will have to finish/exit before eg. going to read-only via remount. Cancelling does not need to check for that. In case the filesystem is forcibly set to read-only after an error, balance will finish anyway and if the cancel call is too fast it will just wait for that to happen. Again does not have to check. Signed-off-by: David Sterba <dsterba@suse.com> --- fs/btrfs/volumes.c | 3 --- 1 file changed, 3 deletions(-)