-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: support for separate metadata volume #55
Comments
This is something we have definitely considered and will likely implement at some point. It is somewhat complicated by the fact that some of VDO's metadata is allocated as needed out of the same region of the underlying storage as the blocks used for storing data. However, it would not be too difficult to move the rest of the metadata to different storage, and doing that is probably sufficient benefit for relatively little work. It also requires some care on the part of the user in the case where storage needs to be added to the VDO, which could require growing both the data and metadata volumes. I know that some users of dm-thin have run into issues with this sort of split where they had plenty of storage to add to their data pool, but couldn't make use of it because they couldn't grow the metadata pool. If you wanted to play with this and were willing to get into the weeds a little bit, I believe we already publish a tool called vdolistmetadata which you can point at a VDO volume, and it will tell you where each of the metadata regions is. If you then wanted to get clever with LVM, you could stitch together your two storage pools manually based on the output of that tool. You'd have to take care if you ever wanted to add more physical storage to your VDO, but otherwise, it should just work. |
Yeah, the ideal would be for a split metadata volume to be optional. |
Agreed. |
This would allow the metadata to be on an NVMe while the data is on an HDD, or for the metadata to use RAID 1 while the data uses RAID 6.
The text was updated successfully, but these errors were encountered: