LINBIT / linstor-server

High Performance Software-Defined Block Storage for container, cloud and virtualisation. Fully integrated with Docker, Kubernetes, Openstack, Proxmox etc.
https://docs.linbit.com/docs/linstor-guide/
GNU General Public License v3.0
954 stars 76 forks source link

Shrink deployed volume #66

Closed Stibila closed 2 years ago

Stibila commented 5 years ago

It would be great if we were able to shrink existing volumes in Linstor. Every layer of our replicated volume supports shrinking, we can manually shrink filesystem residing on DRBD device, DRBD itself supports shrinking, all storage backends support shrinking, but Linstor does not. When I try to shrink VD with existing volumes I get error Deployed volumes can only grow in size, not shrink.

When I bypass Linstor and shrink resource directly with drbdadm resize --size=<new-size> <resource> command, it will work, bud Linstor still shows VD with old size. Is it possible to implement this feature in Linstor?

raltnoeder commented 5 years ago

In general, LINSTOR has a policy of not allowing administrators to shoot themselves in their foot by using LINSTOR commands, because we know from experience that administrators are extremely good at accidentally ruining their systems and losing all their data by doing things the wrong way. And since LINSTOR has no practical way of knowing whether it is safe to discard some of the data on a volume (which is what shrinking does), shrinking volumes has never been implemented. Also, many filesystems do not have the ability to shrink (as far as I know, the widely used XFS is one of them). It is also a feature that very few people ever use. Shrinking would typically only make sense after temporarily using of a lot of storage space, which is normally achieved by creating and mounting additional temporary volumes and deleting those volumes again once they are no longer required.

Stibila commented 5 years ago

Well, we sometime need to shrink volumes for various reasons. I could go to some examples, but I don't think it's necessary.

We do it carefully, with backup and we are prepare to take responsibility if something goes wrong. I know it is not Linstors responsibility to make sure, if it's safe for upper level filesystem to shrink volume and I don't ask for magic button, that will do all the hard work for me.

But currently there is not even hard way to shrink volume. Our storage allow shrinking on every level, but Linstor. We can do it on FileSystem level, then directly on DRBD resource, but we are unable to propagate new size to Linstor. And although only few people/companies will need this function, for those few this may be dealbreaker and the might search for other solutions.

raltnoeder commented 5 years ago

We can take a look at it, however, I am not sure whether it can be implemented in a sane way with reasonable effort. For the same reason, I doubt that other solutions provide clean and safe shrinking capability for block devices that contain data that the storage solution does not know anything about. They may provide hard volume resizing regardless of data loss, which follows an entirely different philosophy.

Stibila commented 5 years ago

They may provide hard volume resizing regardless of data loss, which follows an entirely different philosophy.

Like DRBD itself https://docs.linbit.com/docs/users-guide-9.0/#s-shrinking-online That's all I ask for. With few warnings, maybe even necessity to allow it in configuration so nobody will "shoot themselves in their foot".

raltnoeder commented 5 years ago

It's not that simple. You might have noticed the note "Online shrinking is only supported with external metadata." That's a DRBD limitation, and I think I also know why: DRBD cannot calculate internal meta data size from a volume's net size, which is the value that the user knows, because that's what the filesystem resizes to. While LINSTOR can actually do the calculation to figure out the required backend storage size, that does not help a lot, because DRBD still cannot apply the change on-the-fly. As for external meta data, the possibility to even use that kind of setup is a very recent feature in LINSTOR.

The closest thing to resizing that could be implemented without a lot of effort would be to let LINSTOR reprobe the size of a manually resized device and apply it to its database, instead of complaining about an incorrect volume size or recreating/growing the volume because the size doesn't match.

As I said, it's not a process that is as simple as it may seem, for various reasons, you can trust me on that one, we know DRBD, LINSTOR and the system around it pretty well by now ;)

Stibila commented 5 years ago

Sorry I meant to link off-line shrinking. It is doable with internal metadata and it should suffice in almost any situation. In that case reprobe should be sufficient.

Another option would be implementing external metadata although I am not sure how difficult it is.

You are right that you know DRBD and LINSTOR better than me, but this function is something I really miss. I would love simple "magic button" solution, but i will be satisfied with any working solution.

rp- commented 2 years ago

basic shrink support(as long as the layers support it somehow) was added with 1.8.0