Re: About the thin provision function @ kernel 3.2 or later.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi Ted, Thanks for taking time to look at thinp. On Mon, Jan 16, 2012 at 10:59:59AM -0500, Ted Ts'o wrote: > Thanks for making a pointer to the paper available! I have a question > about one of the slides, where you say: "snapshots of external > origins". Am I correct in suppose this means you can take a snapshot > of something which is currently not a thin-provisioned volume? ... > Is this a feature which is yet to be implemented? And if so, what's > the timeline for implementing it. Yes, that's exactly it. I do want to support it in the near future (2-3 months). There are a few options on this front. i) We only support a read-only external origin. Of course people can use snapshots if they want writeable versions of the current state. An explicit merge facility will need to be added if people want to copy the snap back over the origin. This is by far the simplest approach, and I'll probably start with this - at least in a dev branch. ii) We support read/write origins. When I last looked at this 15 months ago I struggled to come up with a metadata design that allowed both efficient snapshot lookup _and_ efficient snapshot deletion. I'm expecting people to use many, many more snapshots with thinp; deletion performance really is a problem. iii) We add support to patch metadata changes into the running metadata device. This would allow us to map the origin directly into the pools data device (eg, using a linear target). And then introduce a mapping for that origin. This would mean the origin would appear as a thin dev within the pool. This approach greatly improves the performance since we wouldn't have to always COW on the first write to an origin block (i.e. the overlapping block optimisation is still valid). > If this is not a feature to be implemented, can I please put it on the > wishlist? I can imagine a lot of ext4 users who would be interested > in thin-provisioning, especially if there is discard support such than > when we delete a file, we send a discard which causes the > thin-provisioned space in the snapshot to be dropped. (This is also > apparently not implemented, from what I can tell from the source; do > you have an approximate idea of where in the priority list / when it > is scheduled to be implemented?) Discard was in until recently. There were some race conditions associated with it that I didn't have time to work through before the merge window. Expect this to reappear sometime in the next 2-3 months. - Joe -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel