Support non-thin provision and thin provision volumes in one volume backend
Currently, many volume backend drivers only support create one type's volume according to its configuration.
As far as we know, some volume backend drivers based on cluster file system have the capability to support
create non-thin provision and thin provision volumes at the same time, which would could bring the following benefits:
1. It can offer more using flexibility to provide more kinds of volume.
2. It can make full use of volume backend storage, because it can avoid storage pool fragmentation.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Not
- Drafter:
- ling-yun
- Direction:
- Needs approval
- Assignee:
- ling-yun
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
-
next
- Started by
- Completed by
- Sean McGinnis
Related branches
Related bugs
Sprints
Whiteboard
If a particular backend supports specifying thin versus thick then that could/should be exposed via the existing means that we have currently (types/
Is this what you're thinking, or is there something else you have in mind?
====
Yes, it can be done by extra-specs/types.
1. Current Problem
Nnow most of the volume drivers only support one volume type based on configuration.
For glusterfs driver, it only support thin volume or thick volume in one volume backend based on config item of glusterfs_
But glusterfs volume backend has the capability to support thin and thick volume in one volume backend.
Others volume backend drivers also have the same problem.
2. Benifits of this bp:
1) One volume backend support two or more kinds of volumes in one volume backend
Subsuqent volume drivers should support more kinds of volume in one volume backend when implementing, instead only support one kind volume according to current volume drivers.
2) Make full use of volume backend storage, because it can avoid storage pool fragmentation.
According to the current volume drivers' implementation, we need two storage backend to support thin and non-thin volume, which would cause a storage pool fragmentation problem.
If volume driver support thin and non-thin volume in one volume backend, we could put two storage backend pool together to make full use of volume backend storage.
Based on these two points, I think it is necessary to rebase volume drivers and subsuqent volume drivers implement to support more kinds in one volume backend.
-- ling-yun
To my understanding, it is necessary to consider over-provisioning ratio for thin provisioning, for example. -- Jay Xu.
