Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
On Fri, 5 May 2006, Marion Hakanson wrote: > Interesting discussion. I've often been impressed at how NetApp-like > the overal ZFS feature-set is (implies that I like NetApp's). Is it > verboten to compare ZFS to NetApp? I hope not Of course not. And if "Thumper" is similar to the rumoured description published by theregister.com, then it will be widely recognized as a strong NetApp competitor product and invite direct comparison. > NetApp has two ways of making snapshots. There is a set of automatic > snapshots, which are created, rotate and expire on their own (i.e. the > filer does all of this). Often you'll have a number of hourly, daily, > weekly, etc. snapshots in this category. These are the ones that users > can count on seeing when they seek to perform a self-recovery of a > mistakenly damaged file. > > Then you have the ones you create manually, or which are created by > backup software. The filer itself will never delete these, it's up > to the external creator to manage them. > > This has proven to be a fantastic model for the usage patterns that I have > experienced (over probably 6+ years of NetApp use), and I would like to > see something similar available for ZFS. > > Personally, I think that having an expiration time (and creation) be > associated with the snapshot/pool itself is a good thing. What happens > if one exports said filesystem/pool (with snapshots) to another system, > if such creation/expiration is handled by some outside utility? Playing devils advocate and assuming that utility is not a part of zfs [0]: As long as you can access the "serial numbers"[1] that zfs associates with a pool and with pool member disks, an external utility could still maintain the relationship between the snapshot and the pool that it was created from. > Hmm, I'm not sure if the NetApp auto-snapshot schedule follows a disk > volume if it's exported to a different filer. I think it doesn't. > [0] it could be in a zfs contributed software repository [1] really Unique Identifiers Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
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 GonzalezSun Microsystems GmbH, Germany Platform Technology Group, Client Solutionshttp://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
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
On Fri, May 05, 2006 at 09:43:05AM -0700, Marion Hakanson wrote: > Interesting discussion. I've often been impressed at how NetApp-like > the overal ZFS feature-set is (implies that I like NetApp's). Is it > verboten to compare ZFS to NetApp? I hope not It's a public list, you can do the comparison if you like :) Here's what I think: Solaris is a general purpose OS, as such it has scheduling facilities (cron(1M), at(1)) and what not, so it is tempting to say that we need only make it easy to build this kind of facility and much more. And for me better time formatting is a huge part of this (and, to answer the question, like what the date(1) supports, but I'd also like raw time in seconds/microseconds since the epoch). Now, it may be that we really should offer this functinality out of the box, with no scripting being required. Being neither in the ZFS team nor in Marketing I can't say what is planned, if anything. I imagine that Marketing would have some input on this, if they haven't already; and your input may impact what Marketing has to say on this, so keep it coming. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
I agree and I do not say what you do is wrong, I was just expressing my opinion after what happend today on my system that there would be an excelent idea to have such extra feature in ZFS... Regards, Chris On Fri, 5 May 2006, Darren J Moffat wrote: Krzys wrote: Maybe there could be a flag for certain snaps where it could be made read only?!? But I dont know how this could be implemented and I do not think that would be possible... Anyway I still think that if I had a production system with those snaps I would rather remove that "golden image" and continue with operations rather than have no space and put my system to a halt. That may work for you but it might not work for everyone and it certainly doesn't work for my use case. -- Darren J Moffat !DSPAM:122,445b810319014137527416! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
I realy do like the way NetApp is handling snaps :) that would be an excelent thing in ZFS :) On Fri, 5 May 2006, Marion Hakanson wrote: Interesting discussion. I've often been impressed at how NetApp-like the overal ZFS feature-set is (implies that I like NetApp's). Is it verboten to compare ZFS to NetApp? I hope not NetApp has two ways of making snapshots. There is a set of automatic snapshots, which are created, rotate and expire on their own (i.e. the filer does all of this). Often you'll have a number of hourly, daily, weekly, etc. snapshots in this category. These are the ones that users can count on seeing when they seek to perform a self-recovery of a mistakenly damaged file. Then you have the ones you create manually, or which are created by backup software. The filer itself will never delete these, it's up to the external creator to manage them. This has proven to be a fantastic model for the usage patterns that I have experienced (over probably 6+ years of NetApp use), and I would like to see something similar available for ZFS. Personally, I think that having an expiration time (and creation) be associated with the snapshot/pool itself is a good thing. What happens if one exports said filesystem/pool (with snapshots) to another system, if such creation/expiration is handled by some outside utility? Hmm, I'm not sure if the NetApp auto-snapshot schedule follows a disk volume if it's exported to a different filer. I think it doesn't. Regards, Marion ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss !DSPAM:122,445b80b818937266247132! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
Krzys wrote: Maybe there could be a flag for certain snaps where it could be made read only?!? But I dont know how this could be implemented and I do not think that would be possible... Anyway I still think that if I had a production system with those snaps I would rather remove that "golden image" and continue with operations rather than have no space and put my system to a halt. That may work for you but it might not work for everyone and it certainly doesn't work for my use case. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
Interesting discussion. I've often been impressed at how NetApp-like the overal ZFS feature-set is (implies that I like NetApp's). Is it verboten to compare ZFS to NetApp? I hope not NetApp has two ways of making snapshots. There is a set of automatic snapshots, which are created, rotate and expire on their own (i.e. the filer does all of this). Often you'll have a number of hourly, daily, weekly, etc. snapshots in this category. These are the ones that users can count on seeing when they seek to perform a self-recovery of a mistakenly damaged file. Then you have the ones you create manually, or which are created by backup software. The filer itself will never delete these, it's up to the external creator to manage them. This has proven to be a fantastic model for the usage patterns that I have experienced (over probably 6+ years of NetApp use), and I would like to see something similar available for ZFS. Personally, I think that having an expiration time (and creation) be associated with the snapshot/pool itself is a good thing. What happens if one exports said filesystem/pool (with snapshots) to another system, if such creation/expiration is handled by some outside utility? Hmm, I'm not sure if the NetApp auto-snapshot schedule follows a disk volume if it's exported to a different filer. I think it doesn't. Regards, Marion ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
Maybe there could be a flag for certain snaps where it could be made read only?!? But I dont know how this could be implemented and I do not think that would be possible... Anyway I still think that if I had a production system with those snaps I would rather remove that "golden image" and continue with operations rather than have no space and put my system to a halt. :) On Fri, 5 May 2006, Darren J Moffat wrote: Krzys wrote: I did not think of it this way and it is a very valid point, but I still think that most likely you would have a backup already on tape if need be and haveing space available for writing rhather than having no disk space for live data is much more important than a snap, but thats my opinion. I think it certainly should be an option. What if my first snapshot is the golden image of my zones or diskless clients ? I need that online not on a tape. -- Darren J Moffat !DSPAM:122,445b7eed184751123715201! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
Krzys wrote: I did not think of it this way and it is a very valid point, but I still think that most likely you would have a backup already on tape if need be and haveing space available for writing rhather than having no disk space for live data is much more important than a snap, but thats my opinion. I think it certainly should be an option. What if my first snapshot is the golden image of my zones or diskless clients ? I need that online not on a tape. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
I did not think of it this way and it is a very valid point, but I still think that most likely you would have a backup already on tape if need be and haveing space available for writing rhather than having no disk space for live data is much more important than a snap, but thats my opinion. I think it certainly should be an option. :) Chris On Fri, 5 May 2006, Darren J Moffat wrote: Krzys wrote: It would be also nice that if you have many snapshoots and you do run out of space that the oldest snapshoot would be automatically removed untill space is freed up. I did setup this snashoot that is beiing made every minute, then every hour, day and a month, and I finally got to the point where I did run out of space, olders snashoots were not removed space was gone and server could not be used. I was just testing this backup and no harm was done but I think haveing space is the most important, snapshoots are not as critical as beeing able to write to a disk... but hey. just a suggestion. I really wouldn't want that policy. Sometimes the oldest snapshot is the most valuable one of all because they are the "golden egg" that started everything. Though it really depends on what you are using snapshots for. I certainly wouldn't support this policy being the default. -- Darren J Moffat !DSPAM:122,445b7898169711123715201! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
Krzys wrote: It would be also nice that if you have many snapshoots and you do run out of space that the oldest snapshoot would be automatically removed untill space is freed up. I did setup this snashoot that is beiing made every minute, then every hour, day and a month, and I finally got to the point where I did run out of space, olders snashoots were not removed space was gone and server could not be used. I was just testing this backup and no harm was done but I think haveing space is the most important, snapshoots are not as critical as beeing able to write to a disk... but hey. just a suggestion. I really wouldn't want that policy. Sometimes the oldest snapshot is the most valuable one of all because they are the "golden egg" that started everything. Though it really depends on what you are using snapshots for. I certainly wouldn't support this policy being the default. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
On Fri, 5 May 2006, Nicolas Williams wrote: > On Fri, May 05, 2006 at 05:17:43PM +0200, Constantin Gonzalez wrote: > > 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. > > I've some scripts that do something like this (snapshot current, delete > all older snapshots, without forcing it, thus clones keep snapshots > alive). > > Now, the thing about implementing expiration dates is that dealing with > time in shell scripts can be pretty painful -- it'd be nice if zfs get > had better time formatting options. Agreed. A couple of questions: - Do you think that zfs (and other subsystems) should use the ISO8601 time formatting standards? - I've been writing a lot more scripts in python for about a year now. The resulting scripts are easy to read/maintain and runtime performance is not an issue. Well written python is portable and re-usable. Are others writing scripts in other than ksh/csh these days? Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
On Fri, May 05, 2006 at 05:17:43PM +0200, Constantin Gonzalez wrote: > 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. I've some scripts that do something like this (snapshot current, delete all older snapshots, without forcing it, thus clones keep snapshots alive). Now, the thing about implementing expiration dates is that dealing with time in shell scripts can be pretty painful -- it'd be nice if zfs get had better time formatting options. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
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 GonzalezSun Microsystems GmbH, Germany Platform Technology Group, Client Solutionshttp://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
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
On Fri, 5 May 2006, Constantin Gonzalez 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? > > 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. 1) But is this something that belongs in ZFS or is this a backup/restore type tool that is simply a "user" of zfs? > 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. With zfs or with your backup/restore tool? > 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. See 1) above > 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. See 1) 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. Again - this looks like an operational backup/restore policy. Not a ZFS function. > 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". 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. > 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. Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Properties of ZFS snapshots I'd like to see...
It would be also nice that if you have many snapshoots and you do run out of space that the oldest snapshoot would be automatically removed untill space is freed up. I did setup this snashoot that is beiing made every minute, then every hour, day and a month, and I finally got to the point where I did run out of space, olders snashoots were not removed space was gone and server could not be used. I was just testing this backup and no harm was done but I think haveing space is the most important, snapshoots are not as critical as beeing able to write to a disk... but hey. just a suggestion. Chris On Fri, 5 May 2006, Constantin Gonzalez 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? 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 GonzalezSun Microsystems GmbH, Germany Platform Technology Group, Client Solutionshttp://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 !DSPAM:122,445b13fd55112750596! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Properties of ZFS snapshots I'd like to see...
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? 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 GonzalezSun Microsystems GmbH, Germany Platform Technology Group, Client Solutionshttp://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
