[pve-devel] [PATCH] increase zfs default timeout to 30sec

[Fabian Grünbichler]

On Tue, Mar 13, 2018 at 04:28:17PM +0200, Lauri Tirkkonen wrote:
> On Tue, Mar 13 2018 16:12:27 +0200, Lauri Tirkkonen wrote:
> > On Tue, Mar 13 2018 16:06:12 +0200, Lauri Tirkkonen wrote:
> > > Hi,
> > > 
> > > On Tue, Mar 13 2018 09:45:18 +0100, Fabian Grünbichler wrote:
> > > > if you haven't already, please send a signed CLA[1] to
> > > 
> > > looks like you forgot to define [1] :)

I did indeed, sorry :) it was supposed to point to

https://pve.proxmox.com/wiki/Developer_Documentation

> > 
> > Well, I found the CLAs anyway, but I really don't think it's worth
> > bothering our legal dept
> 
> Well, they seemed to be aching for things to do so I did that anyway -
> so maybe we'll get that thing signed. Still, I find it a bit ridiculous
> to do all this for a oneliner (:

while just changing one number to another is probably trivial enough to
not be copyrightable and thus not require a signed CLA, we'd rather not
have to think about where to draw the line and start requiring one (and
of course also hope that you might want to contribute other fixes and/or
features in the future :)). it's easier and simpler to just require it
in general, and it is thankfully only a one-time thing.

with that out of the way, just to summarize the situation:

bumping the timeout a bit (not to 30, but something in the 10-20 range)
might already solve your concrete issue, and is something that could get
merged (we'd have to look at all the code paths that call this piece of
code from the API without forking a worker, because these "run thing
with timeout" tend to accumulate in unfortunate ways, and like Thomas
said we have a 30s limit for the whole API request).

the real fix is to expose more storage operations (and things that imply
storage operations) over the API as workers, so that we can safely bump
the timeouts a lot. this would then require changes on the GUI side as
well to make use of the "workerized" API paths. the biggest hurdle there
is most likely the storage content listing, because that is called often
by the GUI, and can take quite a while on a busy big storage, so we'd
need some kind of client side caching and invalidation/force reload
mechanism.