On 5/5/06, Constantin Gonzalez <[EMAIL PROTECTED]> wrote:
Hi,
(apologies if this has been discussed before, I hope not)
while setting up a script at home to do automatic snapshots, a number of
wishes popped into my mind:
The basic problem with regular snapshotting is that you end up managing
so many of them. Wouldn't it be nice if you could assign an expiration date
to a snapshot?
while reading this thread i did come up with an enhancement that could
make dealing with snapshots better, perhaps we can create a directory
structure under .zfs/snapshot so the user can organise the snapshots
for instance.
cd .zfs/snapshot
mkdir daily
mkdir monthly
mkdir important
then the user could use unix commands like mv to put snapshots where
he needs them it would also make snapshot management easier if i want
to delete all daily snapshots older than a week.
find .zfs/snapshot/daily -ctime +7d
and to create snapshots and place in the special directories
zfs snapshot data/[EMAIL PROTECTED]/05-05-2006
all snapshot directories would start under .zfs/snapshot
James Dickens
uadmin.blogspot.com
For instance:
zfs snapshot -e 3d tank/[EMAIL PROTECTED]
would create a regular snapshot with an expiration date of 3 days from the
date it was created.
You could then change the expiration date with zfs set if you want to keep
it longer. "0" would mean no expiration date and so on.
Then, ZFS would be free to destroy the snapshot to free up space, but only if
it must: Just like the yogurt in your fridge, you may or may not be able to eat
it after the best before date, but you are guaranteed to be able to eat it
(or sue the yogurt company) if it's inside the best before date.
Another property could control the rigidness of this policy: Hard expiration
would destroy the snapshot as soon as the expiry time arrives, soft
expiration would work like the yogurt example above.
The benefits of this approach would be ease of complexity: Imagine you do
a snapshot every week, then you'll have 52 snapshots by the end of one year.
This means that sysadmins will start writing scripts to automatically
delete snapshots they don't need (I'm about to do just that) at the risk
of deleting the wrong snapshot. Or, they won't because it takes too much
thinking (you really want to make that script really robust).
Another set of expiration related properties could allow for more complex
snapshot management:
- Multiple layers of snapshots: Keep one Yearly, one monthly, one weekly
and the snapshot from yesterday always available.
- Multiple priorities: Assign priorities to snapshots so less important
ones get destroyed first.
- Specify date ranges to destroy/modify attributes on multiple snapshots at
once.
Is this something we're already looking at or should we start looking at
this as an RFE?
Thinking further, ZFS could start doing automatic snapshots (invisible from
the user) by just keeping every uber-block at each interval. Then, when the
admin panics, ZFS could say "hmm, here's a couple of leftover snapshots
that happen to still exist because you had a lot space left on the disks
that you may find useful".
The basic idea behind this whole thinking is to maximize utilization of free
blocks. If your disk utilization is only 50%, why not use the other 50% for
snapshots by default, that could save your life?
Best regards,
Constantin
--
Constantin Gonzalez Sun Microsystems GmbH, Germany
Platform Technology Group, Client Solutions http://www.sun.de/
Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
