Re: [zfs-discuss] zfs promote/destroy enhancements?
On Thu, Apr 23, 2009 at 11:25:54AM -0700, Edward Pilatowicz wrote: > an interesting idea. i can file an RFE on this as well, but there are a > couple side effects to consider with this approach. > > setting this property would break "zfs snapshot -r" if there are > multiple snapshots and clones of a single filesystem. I agree. You'd want to make snapshot -r compute new snapshot names in some manner, so you're back to something like "templates," which is why I really like your proposal. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs promote/destroy enhancements?
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote: > Ed, > > "zfs destroy [-r] -p" sounds great. > > I'm not a big fan of the "-t template". Do you have conflicting snapshot > names due to the way your (zones) software works, or are you concerned > about sysadmins creating these conflicting snapshots? If it's the > former, would it be possible to change the zones software to avoid it? > conflicting names are pretty common for zones. the zones infrastructure uses SUNWzoneXXX for zone cloning and zbe-XXX for zone BE management. i guess we could switch to using timestamps... ed ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs promote/destroy enhancements?
On Thu, Apr 23, 2009 at 11:31:07AM -0500, Nicolas Williams wrote: > On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote: > > "zfs destroy [-r] -p" sounds great. > > > > I'm not a big fan of the "-t template". Do you have conflicting snapshot > > names due to the way your (zones) software works, or are you concerned > > about sysadmins creating these conflicting snapshots? If it's the former, > > would it be possible to change the zones software to avoid it? > > I think the -t option -- automatic snapshot name conflict resolution -- > makes a lot of sense in the context of snapshots and clones mostly > managed by a system component (zonedm, beadm) but where users can also > create snapshots (e.g., for time slider, backups): you don't want the > users to create snapshot names that will later prevent zoneadm/beadm > destroy. Making the users responsible for resolving such conflicts > seems not user-friendly to me. > > However, if we could just avoid the conflicts in the first place then > we'd not need an option for automatic snapshot name conflict resolution. > Conflicts could be avoided by requiring that all snapshot names of a > dataset and of clones of snapshots of that dataset, and so on, be > unique. Snapshot name uniqueness could be a property of the root > dataset of a snapshot/clone tree. > an interesting idea. i can file an RFE on this as well, but there are a couple side effects to consider with this approach. setting this property would break "zfs snapshot -r" if there are multiple snapshots and clones of a single filesystem. callers that creates snapshots (ie zones) usually have a simple naming schemes. they look at what snapshots are there and pick a new name that isn't used yet. with this approach, picking a new name becomes harder because iterating over the existing snapshot namespace just became harder. (i guess that callers could adopt a policy of creating snaoshots with incrementing names until they get some return code other than EEXIST.) ed ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs promote/destroy enhancements?
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote: > "zfs destroy [-r] -p" sounds great. > > I'm not a big fan of the "-t template". Do you have conflicting snapshot > names due to the way your (zones) software works, or are you concerned > about sysadmins creating these conflicting snapshots? If it's the former, > would it be possible to change the zones software to avoid it? I think the -t option -- automatic snapshot name conflict resolution -- makes a lot of sense in the context of snapshots and clones mostly managed by a system component (zonedm, beadm) but where users can also create snapshots (e.g., for time slider, backups): you don't want the users to create snapshot names that will later prevent zoneadm/beadm destroy. Making the users responsible for resolving such conflicts seems not user-friendly to me. However, if we could just avoid the conflicts in the first place then we'd not need an option for automatic snapshot name conflict resolution. Conflicts could be avoided by requiring that all snapshot names of a dataset and of clones of snapshots of that dataset, and so on, be unique. Snapshot name uniqueness could be a property of the root dataset of a snapshot/clone tree. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs promote/destroy enhancements?
Ed, "zfs destroy [-r] -p" sounds great. I'm not a big fan of the "-t template". Do you have conflicting snapshot names due to the way your (zones) software works, or are you concerned about sysadmins creating these conflicting snapshots? If it's the former, would it be possible to change the zones software to avoid it? But overall, this sounds pretty reasonable. Could you file an RFE? --matt Edward Pilatowicz wrote: hey all, in both nevada and opensolaris, the zones infrastructure tries to leverage zfs where ever possible. we take advantage of snapshotting and cloning for things like zone cloning and zone be management. because of this, we've recently run into multiple scenarios where a zoneadm uninstall fails. 6787557 zoneadm uninstall fails when zone has zfs clones http://bugs.opensolaris.org/view_bug.do?bug_id=6787557 7491 problems destroying zones with cloned dependents http://defect.opensolaris.org/bz/show_bug.cgi?id=7491 these failures occur when we try to destroy the zfs filesystem associated with a zone, but that filesystem has been snapshotted and cloned. the way we're fixing these problems is by doing a promotion before the destroy. jerry has fixed 6787557 for nevada in zoneadm, but now i'm looking at having to re-implement a similar fix for opensolaris in the ipkg brand for 7491. hence, i'm wondering if it would make more sense just to add this functionality directly into zfs(1m)/libzfs. this would involve enhancements to the zfs promote and destroy subcommands. here's what i'm thinking. the first component would be a new "-t " option to zfs promote. this option would instruct zfs promote to check for snapshot naming collisions between the origin and promotion target filesystems, and to rename any origin filesystem snapshots with conflicting names before attempting the promotion. the conflicting snapshots will be renamed to XXX, where XXX is an integer used to make the snapshot name unique. today users have to do this renaming manually if they want the promotion to succeed. to illustrate how this new functionality would work, say i have the following filesystems/snapshots: tank/zones/zone1 tank/zones/zo...@sunwzone1 tank/zones/zo...@user1 tank/zones/zone2(clone of tank/zones/zo...@sunwzone1) tank/zones/zo...@sunwzone1 if i do a "zfs promote -t SUNWzone tank/zones/zone2", then this would involved a rename of zo...@sunwzone1 to zo...@sunwzone2, and a promotion of tank/zones/zone2. the @user1 snapshot would not be renamed because there was no naming conflict with the filesystem being promoted. hence i would end up with: tank/zones/zone2 tank/zones/zo...@sunwzone1 tank/zones/zo...@sunwzone2 tank/zones/zo...@user1 tank/zones/zone1(clone of tank/zones/zo...@sunwzone2) if i did a "zfs promote -t user tank/zones/zone2", then this would this involved a rename of zo...@sunwzone1 to zo...@user2, and then a promotion of tank/zones/zone2. hence i would end up with: tank/zones/zone2 tank/zones/zo...@sunwzone1 tank/zones/zo...@user1 tank/zones/zo...@user2 tank/zones/zone1(clone of tank/zones/zo...@user2) the second component would be two new flags to zfs destroy: zfs destroy [-p [-t ]] the -p would instruct zfs destroy to try to promote the oldest clone of the youngest snapshot of the filesystem being destroyed before doing the destroy. if the youngest filesystem doesn't have a clone, the command will fail unless -r was specified. if -r was specified we will continue to look through snapshot from youngest to oldest looking for the first one with a clone. if a snapshot with a clone is found, the oldest clone will be promoted before the destroy. if a template was specified via -t, this will be passed through to the promote operation. thoughts? ed ___ 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] Unexpectedly poor 10-disk RAID-Z2 performance?
On Thu, 23 Apr 2009, Rince wrote: I presume I'm missing something, but I have no idea what. Halp? The main thing to be aware of with raidz and raidz2 is that the devices in a vdev are basically "chained together" so that you get an effective one disk's worth of IOPS per vdev. They are very space efficient but not so good for multi-user use. Reporting random read or write thoughput is not a useful measure unless you know how many simultaneous users are going to need that throughput at the same time. The blocksize also makes a difference. Thoughput with 128K blocks is obviously different than with 8K blocks. Since you have 10 disks in your raidz2, they all need to be running similarly very well in order to obtain the optimum performance. Even one pokey disk will cause the whole vdev to suffer. You can use 'iostat -nx 10' (or similar) to discover if you have a pokey disk which is bottlenecking your pool. If your pool design is bottlenecked for IOPS then a single heavy IOPS consumer could cause performance for other users to suffer. Sometimes IOPS consumers may come from unexpected places such as FireFox. Scripts from the DTrace Toolkit can help identify which processes are consuming the IOPS. Using a SSD as your log device will help with higher-level synchronous write performance but it will not be able to heal a problem with your raidz2 vdev, which needs to do individual disk transactions at a lower level. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
