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...
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...
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...
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, 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
