Having to type the full dataset names as arguments to zfs(1M), e.g.
$ zfs snapshot rpool/export/home/ml93401/onnv-clone at onnv_121
$ zfs clone rpool/export/home/ml93401/onnv-clone at onnv_121 \
rpool/export/home/ml93401/ws/somebugfix
$ cd ws/somewbugfix
[do some work]
$ zfs snapshot rpool/export/home/ml93401/ws/somebugfix at 9aug
gets boring quickly and got me thinking that it would be nice if one
could use pathnames in zfs(1M) arguments in addition to dataset names
(''zfs list'' already supports pathnames as arguments).
Some hacking lead to the luxury of being able to this instead:
$ zfs snapshot ./onnv-clone at onnv_121
$ zfs clone ./onnv-clone at onnv_121 ./ws/somebugfix
$ cd ws/somewbugfix
[do some work]
$ zfs snapshot ./@9aug
Is there any particular reason why this is not yet possible (other than
''nobody has done the work'' obviously)? CR 628833 (RFE: allow
filesystem
mountpoints for zfs commands) seems to be the closest to this, but has
been closed as a dup of 6260523 (want ''zfs list <path>'')
without any
information as to why.
Thoughts?
Menno
--
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
On Sun, Aug 9, 2009 at 6:50 AM, Menno Lageman<Menno.Lageman at sun.com> wrote:> Having to type the full dataset names as arguments to zfs(1M), e.g. > > $ zfs snapshot rpool/export/home/ml93401/onnv-clone at onnv_121 > $ zfs clone rpool/export/home/ml93401/onnv-clone at onnv_121 \ > ? ?rpool/export/home/ml93401/ws/somebugfix > $ cd ws/somewbugfix > > [do some work] > > $ zfs snapshot rpool/export/home/ml93401/ws/somebugfix at 9aug > > gets boring quickly and got me thinking that it would be nice if one could > use pathnames in zfs(1M) arguments in addition to dataset names (''zfs list'' > already supports pathnames as arguments). > > Some hacking lead to the luxury of being able to this instead: > > $ zfs snapshot ./onnv-clone at onnv_121 > $ zfs clone ./onnv-clone at onnv_121 ./ws/somebugfix > $ cd ws/somewbugfix > > [do some work] > > $ zfs snapshot ./@9aug > > Is there any particular reason why this is not yet possible (other than > ''nobody has done the work'' obviously)? CR 628833 (RFE: allow filesystem > mountpoints for zfs commands) seems to be the closest to this, but has been > closed as a dup of 6260523 (want ''zfs list <path>'') without any information > as to why.This was previously discussed... http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019762.html I think that the idea was generally well accepted. All that is missing is the ARC case and the code. For the use case of creating snapshots, there is also this: # mkdir .zfs/snapshot/foo # zfs list | grep foo rpool/ROOT/s10u7_zfs at foo 0 - 9.76G - # rmdir .zfs/snapshot/foo # zfs list | grep foo <no output> I don''t know of a similar shortcut for the create or clone subcommands. -- Mike Gerdts http://mgerdts.blogspot.com/
Mike Gerdts wrote:> > This was previously discussed... > > http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019762.htmlThanks for the pointer (I remember this being discussed, but couldn''t find it again). That seems to be pretty much the same as what I came up with. The difference with Darren''s proposal is that mine requires pathname arguments to start with a ''.'' (or ''/'') so the disambiguation is automatic since pool names cannot start with either a ''.'' or a ''/''. ''zfs create tank/foo'' thus refers to the dataset tank/foo, while ''zfs create ./tank/foo'' refers to a dataset relative to the dataset of the current directory (rpool/export/home/ml93401/tank/foo, if the current dir was my home dir).> I think that the idea was generally well accepted. All that is > missing is the ARC case and the code.If someone is willing the sponsor the ARC case, that shouldn''t be a problem. Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
Menno Lageman wrote:> Mike Gerdts wrote: >> >> This was previously discussed... >> >> http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019762.html > > Thanks for the pointer (I remember this being discussed, but couldn''t > find it again). That seems to be pretty much the same as what I came up > with. > > The difference with Darren''s proposal is that mine requires pathname > arguments to start with a ''.'' (or ''/'') so the disambiguation is > automatic since pool names cannot start with either a ''.'' or a ''/''. ''zfs > create tank/foo'' thus refers to the dataset tank/foo, while ''zfs create > ./tank/foo'' refers to a dataset relative to the dataset of the current > directory (rpool/export/home/ml93401/tank/foo, if the current dir was my > home dir). > >> I think that the idea was generally well accepted. All that is >> missing is the ARC case and the code. > > If someone is willing the sponsor the ARC case, that shouldn''t be a > problem.I''ll gladly sponsor the ARC case for you if you are willing to code and test this ready for integration. -- Darren J Moffat
On 08/10/09 11:33, Darren J Moffat wrote:> Menno Lageman wrote: >> Mike Gerdts wrote: >>> >>> This was previously discussed... >>> >>> http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019762.html >> >> Thanks for the pointer (I remember this being discussed, but couldn''t >> find it again). That seems to be pretty much the same as what I came >> up with. >> >> The difference with Darren''s proposal is that mine requires pathname >> arguments to start with a ''.'' (or ''/'') so the disambiguation is >> automatic since pool names cannot start with either a ''.'' or a ''/''. >> ''zfs create tank/foo'' thus refers to the dataset tank/foo, while ''zfs >> create ./tank/foo'' refers to a dataset relative to the dataset of the >> current directory (rpool/export/home/ml93401/tank/foo, if the current >> dir was my home dir). >> >>> I think that the idea was generally well accepted. All that is >>> missing is the ARC case and the code. >> >> If someone is willing the sponsor the ARC case, that shouldn''t be a >> problem. > > I''ll gladly sponsor the ARC case for you if you are willing to code and > test this ready for integration. >Of course, Thanks! Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno