>>>> I was thinking more something like: >>>> >>>> - find all disk devices and slices that have ZFS pools on them >>>> - show users the devices and pool names (and UUIDs and device paths in >>>> case of conflicts).. >>>> >>> >>> I was thinking that device & pool names are too variable, you need to >>> be reading serial numbers or ID's from the device and link to that. >>> >> >> Device names are, but there's no harm in showing them if there's >> something else that's less variable. Pool names are not very variable >> at all. >> > > I was thinking of something a little different. Don't worry about > devices, because you don't send to a device (rather, send to a pool). > So a simple list of source file systems and a list of destinations > would do. I suppose you could work up something with pictures > and arrows, like Nautilus, but that might just be more confusing > than useful.
True, but if this is an end user service, you want something that can create the filesystem for them on their devices. An advanced mode that lets you pick any destination filesystem would be good for network admins, but for end users they're just going to want to point this at their USB drive. > But that is the easy part. The hard part is dealing with the plethora > of failure modes... > -- richard Heh, my response to this is who cares? :-D This is a high level service, it's purely concerned with "backup succeeded" or "backup failed", possibly with an "overdue for backup" prompt if you want to help the user manage the backups. Any other failure modes can be dealt with by the lower level services or by the user. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
