I've run into this myself. (I am in a university setting). after reading bug ID 6431277 (URL below for noobs like myself who didn't know what "see 6431277" meant):
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6431277 ...it's not clear to me how this will be resolved. What I'd really like to see is the ability to specify where the snapshot backing store will be. (more specifically, the ability for the snapshot space to *not* impact the filesystem space). We have a network Appliance box, whose snapshots are very popular for their value as online backups. Netapp charges snapshots to the storage pool, so they don't cost the filesystem anything. I'm drooling over ZFS as an alternative to the expensive netapp hardware/software, but since we sell RAID space but perform backups administratively, I can't have the snapshots consuming people's space. I could increase the filesystem quota to accomodate the snapshots, but since the snapshot size is dynamic, I would have to increase it well beyond the current snapshot size. Once I do that, users *will* fill the space (that they have not paid for). I could tune the size of the filesystem to match the snapshot + filesystem data, but since snapshot size is dynamic, this is impractical. I also have some very small quotas (50 MB) for users, and would like to be able to create snapshots of them going back 30 days or so without it costing the user anything. The snapshots save us tons of time and effort, but they're not worth it to the user to pay for double or triple the space they're currently using, and I don't want the users going over the original quota of 50 MB, so I can't make enough space in the filesystem to make snapshots of their data... it's maddening. If we must contain snapshots inside a filesystem, perhaps it's possible to set a distinct quota for snapshot space vs. live data space? I could then set snapshot quotas for my filesystems arbitrarily large for my administrative backups, or down to the filesystem size or some other value if there has been delegated authority for the filesystem. It would also be nice to be able to make snapshots of parent filesystems that include their descendants. Then, for example, I could create zfspool/grandparent/parent/child ...and set a filesystem quotas on parent, a "user" quota on child, and a "snapshot" quota on grandparent, and this solves most of my problems. in fact, I think a lot of ZFS's hierarchical features would be more valuable if parent filesystems included their descendants (backups and NFS sharing, for example), but I'm sure there are just as many arguments against that as for it. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
