On 09/06/16 18:27, "users-boun...@openvz.org on behalf of Roman Haefeli"
<users-boun...@openvz.org on behalf of reduz...@gmail.com> wrote:
>On Fri, 2016-06-03 at 15:10 +0000, Dmitry Mishin wrote:
>> Hi,
>>
>> On 03/06/16 11:52, "users-boun...@openvz.org on behalf of Roman
>> Haefeli"
>> <users-boun...@openvz.org on behalf of reduz...@gmail.com> wrote:
>>
>> >
>> > Dear All,
>> >
>> > We're considering creating regular snapshots of our containers. The
>> > setup would include deleting the oldest snapshots. While playing
>> > around
>> > with creating and deleting snapshots, I noticed that the root.hdd
>> > file
>> > keeps growing. It seems there is no point at all in deleting old
>> > snapshots for the only purpose of saving disk space. Then I tried
>> > to
>> > reclaim some space back with 'vzctl compact <name>', but it wasn't
>> > able
>> > to reclaim anything. Only when I deleted all snapshots, 'vzctl
>> > compact
>> > <name>' seems to be effective.
>> >
>> > Now, my question is, will there be support in the future to reclaim
>> > space, even if there are snapshots?
>> It's a bit tricky, and that'a why there were no such plans so far.
>> Could you please explain why are you considering regular snapshots?
>> What
>> is a use case?
>
>Our ploop containers have their image on an NFS store. We once had an
>outage of the NFS server and thus a lot of images with broken
>filesystems. We do have backups, but sometimes it would be easier to
>simply switch to a recent snapshot.
>
>Why is it considered special to have a snapshots of the - let's say -
>past 7 days?
Mb because of habit to use simfs?
Please forgive me, if the question sounded offensive, it was not supposed
to be such in any way - the only reason why I ask such questions is that
we as developers lack the knowledge of whole range of community use cases.
And these questions allow us to clarify is the particular use case a
pattern and why.
Thank you for the answer, I've got the idea.
Back to the topic.
Snapshot by its definition is an ability to make a read-only dump of a
Container's (and thus all its hdds) at some time point. The keyword here
is "read-only". Every feature or tool which use this functionality - rely
on this assumption. So, any functionality which would change a 'read-only'
delta - breaks this assumption and thus leads to issues with other
functionality. And that's why nobody performs compacting of snapshots.
The proper analogy here is 'backup' - nobody expects that compact of a
virtual disk will lead to drop of 'unused' data from backups as well.
Possible solution here - is to do not snapshot/backup unused data.
It doesn't worth to modify a snapshot action for this - because:
1) it makes it to be a non-atomic action (only guest OS knows what data is
unused) and
2) it can be easily emulated be a sequence of 2 commands:
a) ploop balloon discard
b) vzctl snapshot
I.e. do discard just before snapshot.
So, I'd recommend:
1) at some point, do a Container's backup, merge all snapshots and run
compact
2) after that, do compact just before any snapshot.
It will not solve the issue completely (because of defragmentation issue),
but IMHO, it is the best what can be achieved now.
And back to the off-topic again:
What are NFS benefits, which outweigh their instability?
Thank you,
Dima.
>
>Roman
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
