Feature #58877
closed
mgr/volumes: regenerate subvolume metadata for possibly broken subvolumes
Added by Venky Shankar about 1 year ago.
Updated 9 months ago.
Category:
Administration/Usability
Backport:
reef,quincy,pacific
Component(FS):
mgr/volumes
Description
In situations where the subvolume metadata is missing/corrupted/untrustable, having a way to regenerate it would be handy for situations where the subvolume needs to be deleted but since the metadata is missing the user has to mount the volume and manually rm -rf </path/to/subvolume>.
Note: Using this interface should be done with utmost care since it can mess up access to a perfectly accessible subvolume, therefore, having a `--yes-i-really-mean-it` for this command would be mandatory.
I did try to reproduce the issue mentioned in the tracker due to which, the feature is required.I found that:
1. If I delete the `.meta` file under `/path/to/subvolume/`
2. or If I corrupt/enter insane values in `.meta` file
even then the `subvolume rm` command works perfectly and the subvolume gets deleted as expected, which contradicts the statement in the description.
Its obvious that it won't work for other commands like `subvolume info` which makes use of `.meta` file.
Neeraj Pratap Singh wrote:
I did try to reproduce the issue mentioned in the tracker due to which, the feature is required.I found that:
1. If I delete the `.meta` file under `/path/to/subvolume/`
2. or If I corrupt/enter insane values in `.meta` file
even then the `subvolume rm` command works perfectly and the subvolume gets deleted as expected, which contradicts the statement in the description.
Its obvious that it won't work for other commands like `subvolume info` which makes use of `.meta` file.
Yes, you are right, the subvolume rm goes through successfully because it assumes it has legacy subvolume and proceeds with deletion if it doesn't find the
.meta file. So just need to check what's the behavior in the previous versions. We observed this with some user. Need to check behavior in that version.
Thanks,
Kotresh H R
Kotresh Hiremath Ravishankar wrote:
Neeraj Pratap Singh wrote:
I did try to reproduce the issue mentioned in the tracker due to which, the feature is required.I found that:
1. If I delete the `.meta` file under `/path/to/subvolume/`
2. or If I corrupt/enter insane values in `.meta` file
even then the `subvolume rm` command works perfectly and the subvolume gets deleted as expected, which contradicts the statement in the description.
Its obvious that it won't work for other commands like `subvolume info` which makes use of `.meta` file.
Yes, you are right, the subvolume rm goes through successfully because it assumes it has legacy subvolume and proceeds with deletion if it doesn't find the
.meta file. So just need to check what's the behavior in the previous versions. We observed this with some user. Need to check behavior in that version.
Would this be fixed by just backporting a (set of already existing) commits then?
Venky Shankar wrote:
Kotresh Hiremath Ravishankar wrote:
Neeraj Pratap Singh wrote:
I did try to reproduce the issue mentioned in the tracker due to which, the feature is required.I found that:
1. If I delete the `.meta` file under `/path/to/subvolume/`
2. or If I corrupt/enter insane values in `.meta` file
even then the `subvolume rm` command works perfectly and the subvolume gets deleted as expected, which contradicts the statement in the description.
Its obvious that it won't work for other commands like `subvolume info` which makes use of `.meta` file.
Yes, you are right, the subvolume rm goes through successfully because it assumes it has legacy subvolume and proceeds with deletion if it doesn't find the
.meta file. So just need to check what's the behavior in the previous versions. We observed this with some user. Need to check behavior in that version.
Would this be fixed by just backporting a (set of already existing) commits then?
@Kotresh Hiremath Ravishankar Any thoughts on this.
- Target version changed from v18.0.0 to v19.0.0
- Backport changed from pacific,quincy to reef,quincy,pacific
Venky, Neeraj and me had a meeting regarding this and please find the meeting minutes below:
1. When the subvolume metadata file is corrupted/truncated, it is treated as legacy subvolume and legacy config file is generated (This feature is added recently as part of security fixes). With legacy config file, subvolume rm goes through but few operations like subvolume info fails. So generating metadata config file is required in certain cases.
2. To generate the metadata config file, we need to identify the subvolume version. We could rely on 'ceph.dir.layout.pool' xattr on the 'uuid' directory to distinguish whether it's legacy subvolume or not. But if the user/application using the subvolume creates it's own uuid directory to write data and manually sets the layout, then this fails. We need to think of a better way.
3. Since the subvolume operations are idempotent, can we use the subvolume create with force option to regenerate the config file? Need to further check on this.
Thanks,
Kotresh H R
@Neeraj,
Could you please check on the point 3 mentioned in the comment 6 above ?
-Kotresh H R
- Status changed from New to Rejected
Update from internal discussion:
Given the complexities involved with the details mentioned in note-6, its risky to use the proposed interface to regenerate subvolume metadata - the risk being unable to identify a custom (user) .meta file with the one maintained by mgr/volumes.
That said, this feature has bought up the discussion (again) to switch using a separate metadata store for subvolume metadata (and subvolume auth). That will be discussed in a separate tracker (which will be linked to this issue for brevity).
Also available in: Atom
PDF