Hi Al,
1) But is this something that belongs in ZFS or is this a backup/restore
type tool that is simply a "user" of zfs?
...
Again - this looks like an operational backup/restore policy. Not a ZFS
function.
So the question is: Is advanced management of snapshots (aging, expiring,
etc.) something left to the domain of a ZFS user (backup/restore application,
administrator, script) or should these concepts be adopted by ZFS as a
filesystem (which BTW is already much more).
IMHO, backup/restore is much more than playing with snapshots. The dividing
line starts when you copy your data to a different medium. As soon as the
data stays on the disk, I wouldn't say it's backup/restore related. As long
as it's just snapshots, it should be definitely not be called "backup/restore".
But you're right in that my desired functionality can "easily" be implemented
with scripts. Then I would still argue for including this functionality as
part of the ZFS user interface, because of ease of use and minimization of
possible errors for the administrator. If it ain't simple to use, chances
are that people won't. Same goes for snapshots: If admins don't have a really
easy way to get rid of them, chances are they will use them less.
Another point of view might be ease of implementation. A few person-months spent
at Sun (or the OpenSolaris developer community) might come up with a more
robust, clean, efficient, bug-free, elegant way of achieving the task of
snapshot management than millions of person-months in many admins creating
scripts and re-inventing wheels that may be half-baked.
But yes, it is a matter of interpretation who should take care of managing
snapshots after they've been created, ZFS or some application/script/user
action.
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".
Now you're describing a form of filesystem snapshotting function that
might have to be closely integrated with zfs. This is in addition to the
other data replication features that are already in the pipeline for zfs.
Yes, this is when the above discussed features definitively cross the line
towards ZFS' responsibilities.
Actually, it would be cool if ZFS took a hidden snapshot each time a zfs or
zpool command is issued. Then an admin could say "zfs undo" after she/he
discovered that she/he just did a horrible mistake.
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?
IMHO the majority of the functionality you're describing belongs in a
backup/restore tool that is simply a consumer of zfs functionality. And
this functionality could be easily scripted using your scripting tool of
choice.
yes and no, depending on the interpretation. The potential of having a
"zfs undo" subcommand and the automatic exploitation of free space on disk
for keeping snapshots as part of overall snapshot management are definitely
something that ZFS can do much better internally, as opposed to having to
implement it with some other app.
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
