Message ID | 20191204081735.852438-6-naohiro.aota@wdc.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | btrfs: zoned block device support | expand |
On Wed, Dec 04, 2019 at 05:17:12PM +0900, Naohiro Aota wrote: [...] > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > index 616f5abec267..d411574298f4 100644 > --- a/fs/btrfs/super.c > +++ b/fs/btrfs/super.c > @@ -442,8 +442,12 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, > cache_gen = btrfs_super_cache_generation(info->super_copy); > if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE)) > btrfs_set_opt(info->mount_opt, FREE_SPACE_TREE); > - else if (cache_gen) > - btrfs_set_opt(info->mount_opt, SPACE_CACHE); > + else if (cache_gen) { > + if (btrfs_fs_incompat(info, HMZONED)) > + WARN_ON(1); > + else > + btrfs_set_opt(info->mount_opt, SPACE_CACHE); > + } I would probably write this as follows: else if (cache_gen) if (!WARN_ON(btrfs_fs_incompat(info, HMZONED))) btrfs_set_opt(info->mount_opt, SPACE_CACHE);
On Wed, Dec 04, 2019 at 05:17:12PM +0900, Naohiro Aota wrote: > As updates to the space cache are in-place, the space cache cannot be > located over sequential zones and there is no guarantees that the device > will have enough conventional zones to store this cache. Resolve this > problem by disabling completely the space cache. This does not introduces > any problems with sequential block groups: all the free space is located > after the allocation pointer and no free space before the pointer. There is > no need to have such cache. > > Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> > --- > fs/btrfs/hmzoned.c | 18 ++++++++++++++++++ > fs/btrfs/hmzoned.h | 5 +++++ > fs/btrfs/super.c | 10 ++++++++-- > 3 files changed, 31 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/hmzoned.c b/fs/btrfs/hmzoned.c > index b74581133a72..1c015ed050fc 100644 > --- a/fs/btrfs/hmzoned.c > +++ b/fs/btrfs/hmzoned.c > @@ -253,3 +253,21 @@ int btrfs_check_hmzoned_mode(struct btrfs_fs_info *fs_info) > out: > return ret; > } > + > +int btrfs_check_mountopts_hmzoned(struct btrfs_fs_info *info) > +{ > + if (!btrfs_fs_incompat(info, HMZONED)) > + return 0; > + > + /* > + * SPACE CACHE writing is not CoWed. Disable that to avoid > + * write errors in sequential zones. Please format comments to 80 columns > + */ > + if (btrfs_test_opt(info, SPACE_CACHE)) { > + btrfs_err(info, > + "cannot enable disk space caching with HMZONED mode"); "space cache v1 not supported in HMZONED mode, use v2 (free-space-tree)" > + return -EINVAL; > static inline bool btrfs_dev_is_sequential(struct btrfs_device *device, u64 pos) > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > index 616f5abec267..d411574298f4 100644 > --- a/fs/btrfs/super.c > +++ b/fs/btrfs/super.c > @@ -442,8 +442,12 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, > cache_gen = btrfs_super_cache_generation(info->super_copy); > if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE)) > btrfs_set_opt(info->mount_opt, FREE_SPACE_TREE); > - else if (cache_gen) > - btrfs_set_opt(info->mount_opt, SPACE_CACHE); > + else if (cache_gen) { > + if (btrfs_fs_incompat(info, HMZONED)) > + WARN_ON(1); So this is supposed to catch invalid combination, hmzoned-compatible options are verified at the beginning. 'cache_gen' can be potentially non-zero (fuzzed image, accidental random overwrite from last time), so I think a message should be printed. If it's possible to continue, eg. completely ignoring the existing space cache that's more user friendly than a plain unexplained WARN_ON.
On Thu, Dec 05, 2019 at 04:39:53PM +0100, David Sterba wrote: >On Wed, Dec 04, 2019 at 05:17:12PM +0900, Naohiro Aota wrote: >> As updates to the space cache are in-place, the space cache cannot be >> located over sequential zones and there is no guarantees that the device >> will have enough conventional zones to store this cache. Resolve this >> problem by disabling completely the space cache. This does not introduces >> any problems with sequential block groups: all the free space is located >> after the allocation pointer and no free space before the pointer. There is >> no need to have such cache. >> >> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> >> --- >> fs/btrfs/hmzoned.c | 18 ++++++++++++++++++ >> fs/btrfs/hmzoned.h | 5 +++++ >> fs/btrfs/super.c | 10 ++++++++-- >> 3 files changed, 31 insertions(+), 2 deletions(-) >> >> diff --git a/fs/btrfs/hmzoned.c b/fs/btrfs/hmzoned.c >> index b74581133a72..1c015ed050fc 100644 >> --- a/fs/btrfs/hmzoned.c >> +++ b/fs/btrfs/hmzoned.c >> @@ -253,3 +253,21 @@ int btrfs_check_hmzoned_mode(struct btrfs_fs_info *fs_info) >> out: >> return ret; >> } >> + >> +int btrfs_check_mountopts_hmzoned(struct btrfs_fs_info *info) >> +{ >> + if (!btrfs_fs_incompat(info, HMZONED)) >> + return 0; >> + >> + /* >> + * SPACE CACHE writing is not CoWed. Disable that to avoid >> + * write errors in sequential zones. > >Please format comments to 80 columns > Fixed, thanks. >> + */ >> + if (btrfs_test_opt(info, SPACE_CACHE)) { >> + btrfs_err(info, >> + "cannot enable disk space caching with HMZONED mode"); > >"space cache v1 not supported in HMZONED mode, use v2 (free-space-tree)" > >> + return -EINVAL; Yes, we can technically use free-space-tree on HMZONED mode. But, since HMZONED mode now always allocate extents in a block group sequentially regardless of underlying device zone type, it's no use to enable and maintain the tree anymore. So, just telling "space cache v1 not supported in HMZONED mode" is better? >> static inline bool btrfs_dev_is_sequential(struct btrfs_device *device, u64 pos) >> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c >> index 616f5abec267..d411574298f4 100644 >> --- a/fs/btrfs/super.c >> +++ b/fs/btrfs/super.c >> @@ -442,8 +442,12 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, >> cache_gen = btrfs_super_cache_generation(info->super_copy); >> if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE)) >> btrfs_set_opt(info->mount_opt, FREE_SPACE_TREE); >> - else if (cache_gen) >> - btrfs_set_opt(info->mount_opt, SPACE_CACHE); >> + else if (cache_gen) { >> + if (btrfs_fs_incompat(info, HMZONED)) >> + WARN_ON(1); > >So this is supposed to catch invalid combination, hmzoned-compatible >options are verified at the beginning. 'cache_gen' can be potentially >non-zero (fuzzed image, accidental random overwrite from last time), so >I think a message should be printed. If it's possible to continue, eg. >completely ignoring the existing space cache that's more user friendly >than a plain unexplained WARN_ON. We can just ignore the generation value and continue. I'll rewrite to use btrfs_info(info, "ignoring existing space cache in HMZONED mode.") instead of WARN_ON. Thanks,
On Fri, Dec 06, 2019 at 02:32:44PM +0900, Naohiro Aota wrote: > >> + */ > >> + if (btrfs_test_opt(info, SPACE_CACHE)) { > >> + btrfs_err(info, > >> + "cannot enable disk space caching with HMZONED mode"); > > > >"space cache v1 not supported in HMZONED mode, use v2 (free-space-tree)" > > > >> + return -EINVAL; > > Yes, we can technically use free-space-tree on HMZONED mode. But, > since HMZONED mode now always allocate extents in a block group > sequentially regardless of underlying device zone type, it's no use to > enable and maintain the tree anymore. > > So, just telling "space cache v1 not supported in HMZONED mode" is > better? Ok. That v2 is possible to use but not necessary is something to put to documentation. > >> static inline bool btrfs_dev_is_sequential(struct btrfs_device *device, u64 pos) > >> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > >> index 616f5abec267..d411574298f4 100644 > >> --- a/fs/btrfs/super.c > >> +++ b/fs/btrfs/super.c > >> @@ -442,8 +442,12 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, > >> cache_gen = btrfs_super_cache_generation(info->super_copy); > >> if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE)) > >> btrfs_set_opt(info->mount_opt, FREE_SPACE_TREE); > >> - else if (cache_gen) > >> - btrfs_set_opt(info->mount_opt, SPACE_CACHE); > >> + else if (cache_gen) { > >> + if (btrfs_fs_incompat(info, HMZONED)) > >> + WARN_ON(1); > > > >So this is supposed to catch invalid combination, hmzoned-compatible > >options are verified at the beginning. 'cache_gen' can be potentially > >non-zero (fuzzed image, accidental random overwrite from last time), so > >I think a message should be printed. If it's possible to continue, eg. > >completely ignoring the existing space cache that's more user friendly > >than a plain unexplained WARN_ON. > > We can just ignore the generation value and continue. I'll rewrite to > use btrfs_info(info, "ignoring existing space cache in HMZONED mode.") > instead of WARN_ON. Sounds good.
diff --git a/fs/btrfs/hmzoned.c b/fs/btrfs/hmzoned.c index b74581133a72..1c015ed050fc 100644 --- a/fs/btrfs/hmzoned.c +++ b/fs/btrfs/hmzoned.c @@ -253,3 +253,21 @@ int btrfs_check_hmzoned_mode(struct btrfs_fs_info *fs_info) out: return ret; } + +int btrfs_check_mountopts_hmzoned(struct btrfs_fs_info *info) +{ + if (!btrfs_fs_incompat(info, HMZONED)) + return 0; + + /* + * SPACE CACHE writing is not CoWed. Disable that to avoid + * write errors in sequential zones. + */ + if (btrfs_test_opt(info, SPACE_CACHE)) { + btrfs_err(info, + "cannot enable disk space caching with HMZONED mode"); + return -EINVAL; + } + + return 0; +} diff --git a/fs/btrfs/hmzoned.h b/fs/btrfs/hmzoned.h index 8e17f64ff986..d9ebe11afdf5 100644 --- a/fs/btrfs/hmzoned.h +++ b/fs/btrfs/hmzoned.h @@ -29,6 +29,7 @@ int btrfs_get_dev_zone(struct btrfs_device *device, u64 pos, int btrfs_get_dev_zone_info(struct btrfs_device *device); void btrfs_destroy_dev_zone_info(struct btrfs_device *device); int btrfs_check_hmzoned_mode(struct btrfs_fs_info *fs_info); +int btrfs_check_mountopts_hmzoned(struct btrfs_fs_info *info); #else /* CONFIG_BLK_DEV_ZONED */ static inline int btrfs_get_dev_zone(struct btrfs_device *device, u64 pos, struct blk_zone *zone) @@ -48,6 +49,10 @@ static inline int btrfs_check_hmzoned_mode(struct btrfs_fs_info *fs_info) btrfs_err(fs_info, "Zoned block devices support is not enabled"); return -EOPNOTSUPP; } +static inline int btrfs_check_mountopts_hmzoned(struct btrfs_fs_info *info) +{ + return 0; +} #endif static inline bool btrfs_dev_is_sequential(struct btrfs_device *device, u64 pos) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 616f5abec267..d411574298f4 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -442,8 +442,12 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, cache_gen = btrfs_super_cache_generation(info->super_copy); if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE)) btrfs_set_opt(info->mount_opt, FREE_SPACE_TREE); - else if (cache_gen) - btrfs_set_opt(info->mount_opt, SPACE_CACHE); + else if (cache_gen) { + if (btrfs_fs_incompat(info, HMZONED)) + WARN_ON(1); + else + btrfs_set_opt(info->mount_opt, SPACE_CACHE); + } /* * Even the options are empty, we still need to do extra check @@ -879,6 +883,8 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, ret = -EINVAL; } + if (!ret) + ret = btrfs_check_mountopts_hmzoned(info); if (!ret && btrfs_test_opt(info, SPACE_CACHE)) btrfs_info(info, "disk space caching is enabled"); if (!ret && btrfs_test_opt(info, FREE_SPACE_TREE))
As updates to the space cache are in-place, the space cache cannot be located over sequential zones and there is no guarantees that the device will have enough conventional zones to store this cache. Resolve this problem by disabling completely the space cache. This does not introduces any problems with sequential block groups: all the free space is located after the allocation pointer and no free space before the pointer. There is no need to have such cache. Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> --- fs/btrfs/hmzoned.c | 18 ++++++++++++++++++ fs/btrfs/hmzoned.h | 5 +++++ fs/btrfs/super.c | 10 ++++++++-- 3 files changed, 31 insertions(+), 2 deletions(-)