Security Notification
#80 — pyzfs not implemented [WAS: "zfs hold" works to add holds, "zfs holds" doesn't work to view them]
| State | Confirmed |
|---|---|
| Version: | 0.6.9 |
| Area | User interface |
| Issue type | Bug |
| Severity | Medium |
| Submitted by | Bryan Pendleton |
| Submitted on | Jul 21, 2010 |
| Responsible | Seth Heeren |
| Target release: |
—
|
Last modified on
Jul 26, 2010
I am able to set a hold on a snapshot using "zfs hold tag pool@snapshot", but when I execute "zfs holds" to list existing holds, I'm given the cryptic error "internal error: /usr/lib/zfs/pyzfs.py not found"
- Steps to reproduce:
- zfs hold tag pool@snapshot
zfs holds
Added by
Bryan Pendleton
on
Jul 21, 2010 11:34 AM
Not sure about the "proper" fix, but anyone else running into this might like to know that you can get an idea of what holds might be in place by inspecting your "zpool history" output.
Unfortunately, I'm not sure that "zpool release" works right now, in any case.
Unfortunately, I'm not sure that "zpool release" works right now, in any case.
Added by
Seth Heeren
on
Jul 23, 2010 02:49 PM
Issue state:
unconfirmed → postponed
Responsible manager:
(UNASSIGNED) → sgheeren
Currently pyzfs has has not been ported to zfs-fuse
This is blocking a few subcommands of zfs; some of the commands get replaced by less fullfeatured C-coded versions.
In general the areas are rolebased accounting and reporting and they are not high-priority. If someone with a little time on their hands want to start porting pyzfs, we would be most grateful.
Perhaps in time we could have derived works like the time-slider nautilus extension!
This is blocking a few subcommands of zfs; some of the commands get replaced by less fullfeatured C-coded versions.
In general the areas are rolebased accounting and reporting and they are not high-priority. If someone with a little time on their hands want to start porting pyzfs, we would be most grateful.
Perhaps in time we could have derived works like the time-slider nautilus extension!
Added by
Bryan Pendleton
on
Jul 23, 2010 03:11 PM
Perhaps, if this bug is going to continue to exist, then "zfs hold" should be disabled? Apparently, it is possible to set a hold, but not release it. Should I open a separate issue for that?
Added by
Seth Heeren
on
Jul 23, 2010 03:22 PM
Issue state:
postponed → open
Erm... I don't know
I don't use holds,
is 'zfs holds' needed to release the hold? I did not take that away from the original report. I read it to mean that 'zfs holds' merely lists the holds.
I'd be happy to change the issue title back if this is in fact a stopper in that way
I don't use holds,
is 'zfs holds' needed to release the hold? I did not take that away from the original report. I read it to mean that 'zfs holds' merely lists the holds.
I'd be happy to change the issue title back if this is in fact a stopper in that way
Added by
Bryan Pendleton
on
Jul 23, 2010 03:31 PM
When I reported the issue, I hadn't realized that "release" wasn't working either. When you do a "zfs release" it gives command line guidance, but add any more arguments and it gives you a full list of possible commands (which ommits hold, holds, and release). Not sure if the command is just blocked, or if release isn't implemented. No need for "holds", just maybe not nice to allow us to set a hold with "zfs hold" if "zfs release" is unavailable.
Added by
Seth Heeren
on
Jul 23, 2010 03:58 PM
Ok that seems odd. i will look into it a bit later
For the moment: the following are not supported:
sehe@lucid:~/custom/_ZFS$ grep zfs_do_python src/cmd/zfs/zfs_main.c
static int zfs_do_python(int argc, char **argv);
{ "allow", zfs_do_python, HELP_ALLOW },
{ "unallow", zfs_do_python, HELP_UNALLOW },
{ "holds", zfs_do_python, HELP_HOLDS },
zfs_do_python(int argc, char **argv)
Note that 'zfs userspace' is partly supported by fallback C-version
For the moment: the following are not supported:
sehe@lucid:~/custom/_ZFS$ grep zfs_do_python src/cmd/zfs/zfs_main.c
static int zfs_do_python(int argc, char **argv);
{ "allow", zfs_do_python, HELP_ALLOW },
{ "unallow", zfs_do_python, HELP_UNALLOW },
{ "holds", zfs_do_python, HELP_HOLDS },
zfs_do_python(int argc, char **argv)
Note that 'zfs userspace' is partly supported by fallback C-version
Added by
Seth Heeren
on
Jul 23, 2010 06:29 PM
I can release a hold just fine using the maint branch. I assume you should be able to do as much. Are you sure you sepcify the tag (correctly)?
Here is what I did on my system:
sehe@lucid:/tmp$ dd of=backing.vdev bs=512M seek=1024 count=0
sehe@lucid:/tmp$ zpool create sparse /tmp/backing.vdev
sehe@lucid:/tmp$ zfs snapshot -r sparse@now
sehe@lucid:/tmp$ zfs hold -r sparse@now
usage:
hold [-r] <tag> <snapshot> ...
For the property list, run: zfs set|get
For the delegated permission list, run: zfs allow|unallow
sehe@lucid:/tmp$ zfs hold -r mytag sparse@now
sehe@lucid:/tmp$ zfs release -r yourtag sparse@now
cannot release 'yourtag' from 'sparse@now': no such tag on this dataset
sehe@lucid:/tmp$ zfs release -r mytag sparse@now
Indeed, when you try to use 'holds' you get the expected error:
sehe@lucid:/tmp$ zfs holds
internal error: /usr/lib/zfs/pyzfs.py not found
Here is what I did on my system:
sehe@lucid:/tmp$ dd of=backing.vdev bs=512M seek=1024 count=0
sehe@lucid:/tmp$ zpool create sparse /tmp/backing.vdev
sehe@lucid:/tmp$ zfs snapshot -r sparse@now
sehe@lucid:/tmp$ zfs hold -r sparse@now
usage:
hold [-r] <tag> <snapshot> ...
For the property list, run: zfs set|get
For the delegated permission list, run: zfs allow|unallow
sehe@lucid:/tmp$ zfs hold -r mytag sparse@now
sehe@lucid:/tmp$ zfs release -r yourtag sparse@now
cannot release 'yourtag' from 'sparse@now': no such tag on this dataset
sehe@lucid:/tmp$ zfs release -r mytag sparse@now
Indeed, when you try to use 'holds' you get the expected error:
sehe@lucid:/tmp$ zfs holds
internal error: /usr/lib/zfs/pyzfs.py not found
Added by
(anonymous)
on
Jul 26, 2010 10:19 AM
Sorry, yes, I can confirm that "release" does work correctly. I had mangled the snapshot name in my tests, because of a copy-and-paste error, but, after I fixed that, I was able to "release" holds, just not list them using the "zfs holds" command. I think this issue is correct now.
