On Tue, Mar 13 2018 09:45:18 +0100, Fabian Grünbichler wrote:
> On Mon, Mar 12, 2018 at 04:06:47PM +0200, Lauri Tirkkonen wrote:
> > busy pools can easily take more than 5 seconds for eg. zfs create
> > ---
> > PVE/Storage/ZFSPoolPlugin.pm | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
> > index e864a58..7ba035f 100644
> > --- a/PVE/Storage/ZFSPoolPlugin.pm
> > +++ b/PVE/Storage/ZFSPoolPlugin.pm
> > @@ -167,7 +167,7 @@ sub path {
> > sub zfs_request {
> > my ($class, $scfg, $timeout, $method, @params) = @_;
> >
> > - my $default_timeout = PVE::RPCEnvironment->is_worker() ? 60*60 : 5;
> > + my $default_timeout = PVE::RPCEnvironment->is_worker() ? 60*60 : 30;
>
> unfortunately, this is not the way to solve this. our API has a timeout
> per request, so things that (can) take a long time should run in a
> worker (the API then returns the ID of the task, which can be queried
> over the API to retrieve status and/or output).
This did solve our immediate issue: adding a disk to an existing VM from
the web UI failed with timeout, when the pool had some load on it. (A
side note: SIGKILLing the zfs process won't make it exit any faster if
it's waiting in kernel, which it likely is).
Obviously you are free to solve the underlying issue(s) any way you
wish, we just wanted to share our fix. 5 seconds just isn't enough.
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
