zfs discuss - Jun 2007 - Wishlist items

I''ve been saving up a few wishlist items for zfs. Time to share.

1. A verbose (-v) option to the zfs commandline.

In particular zfs sometimes takes a while to return from zfs snapshot -r 
tank/volumes at foo in the case where there are a great many iscsi shared 
volumes underneath. A little progress feedback would go a long way. In 
general I feel the zfs tools lack sufficient feedback and/or logging of 
actions, and this''d be a great start.

2. LUN management and/or general iscsi integration enhancement

Some of these iscsi volumes I''d like to be under the same target but
with
different LUNs. A means for mapping that would be excellent. As would a 
means to specify the IQN explicitly, and the set of permitted initiators.

3. zfs rollback on clones. It should be possible to rollback a clone to 
the origin snapshot, yes? Right now the tools won''t allow it. I know I
can
hack in a race-sensitive snapshot of the new volume immediately after 
cloning, but I already have many hundreds of entities and I''m trying
not
to proliferate them.

Similarly the ability to do zfs send -i [clone origin snapshot1] snapshot2 
in order to efficiently transmit/backup clones would be terrific.

- Joshua



This email, including any attachments, is intended only for the use of the
individual or entity named above and may contain information that is
confidential and privileged. Any information contained in this email is not to
be used or disclosed for any purpose other than the purpose for which you
received it. If you are not the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received this
email by mistake, please delete this email permanently from your system.
WARNING: Although Editure has taken reasonable precautions to ensure no viruses
are present in this email, Editure can not accept responsibility for any losses
or damages whatsoever, arising from the use of this email and/or its
attachments.
www.editure.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070626/285eec8c/attachment.html>

On 26/06/2007, at 12:08 PM, Joshua.Goodall at editure.com
wrote:
> I''ve been saving up a few wishlist items for zfs. Time to share.
>
> 1. A verbose (-v) option to the zfs commandline.
>
> In particular zfs sometimes takes a while to return from zfs  
> snapshot -r tank/volumes at foo in the case where there are a great  
> many iscsi shared volumes underneath. A little progress feedback  
> would go a long way. In general I feel the zfs tools lack  
> sufficient feedback and/or logging of actions, and this''d be a  
> great start.
Since IIRC snapshot -r is supposed to be atomic (one TXG) I''m not  
sure that progress reports would be meaningful.

Have you seen zpool history?
> 2. LUN management and/or general iscsi integration enhancement
>
> Some of these iscsi volumes I''d like to be under the same target  
> but with different LUNs. A means for mapping that would be  
> excellent. As would a means to specify the IQN explicitly, and the  
> set of permitted initiators.
>
> 3. zfs rollback on clones. It should be possible to rollback a  
> clone to the origin snapshot, yes? Right now the tools won''t allow
> it. I know I can hack in a race-sensitive snapshot of the new  
> volume immediately after cloning, but I already have many hundreds  
> of entities and I''m trying not to proliferate them.
Yes, since rollback only takes the snapshot as an argument there  
seems not to be a way to rollback a clone to the "fork" snapshot.

You could, of course just blow away the clone and make a new one from  
the same snapshot
> Similarly the ability to do zfs send -i [clone origin snapshot1]  
> snapshot2 in order to efficiently transmit/backup clones would be  
> terrific.
It seems that a way to use clonename at snapname as an alias for  
origin at snapname would solve both of these problems, at least at the  
user interface level.

On Tue, 26 Jun 2007 Joshua.Goodall at editure.com wrote:
> In particular zfs sometimes takes a while to return from zfs snapshot -r
> tank/volumes at foo in the case where there are a great many iscsi shared
> volumes underneath. A little progress feedback would go a long way.
This would certainly be nice to have.  There is work being done to make
mounting at boot time more observable (see PSARC/2007/273) but a more
general mechanism would be good.  Note that the actual snapshot is a
single ioctl call, but the iscsi and sharenfs fiddling would be user-level
observable.
> In general I feel the zfs tools lack sufficient feedback and/or logging
> of actions, and this''d be a great start.
Have you played with ''zpool history''?
> 2. LUN management and/or general iscsi integration enhancement
[this I have to leave to those more knowledgable]
> 3. zfs rollback on clones. It should be possible to rollback a clone to
> the origin snapshot, yes? Right now the tools won''t allow it.
I know you already know this, but anyway... you can do it in two steps:
  # zfs destroy pool/clone
  # zfs clone pool/filesystem at snapshot pool/clone

Of course, this means briefly unmounting your clone filesystem, but the
rollback does that now anyway (see 6472202), so even the
snapshot-after-rollback workaround you proposed would have the same
problem.

Any properties you set on the original clone would have to be set again on
the new clone.
> Similarly the ability to do zfs send -i [clone origin snapshot1] snapshot2
> in order to efficiently transmit/backup clones would be terrific.
I''m not sure exactly what you mean here.  Could you give an example of
the
way it works now vs. the way you want it to work?


Regards,
markm