maindavfs2 - Support: sr #108607, Locks are not refreshed, if...

 
 

sr #108607: Locks are not refreshed, if flooded with upcalls

Submitter:  Stefan Siegl <stesie>
Submitted:  Wed 02 Jul 2014 03:43:13 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 10 Aug 2014 10:52:39 AM UTC, comment #2: 

Fixed in the CVS sources, branch MAIN and branch rel-1-4-6

- <_71007>
Sun 06 Jul 2014 09:37:37 AM UTC, comment #1: 

Yes, I see the bug.

The proper solution would of course be to make davfs2 multit-hreaded. But until then it must be fixed with a single thread.

The current logic is this:
- upcalls have higher priority then file uploads (mostly ok)
- tidy cache is called at least every idle_time seconds (mostly ok)
- lock-refresh is handled the same way as file uploads. That's wrong.

Lock refresh needs the highest priority.

Calling some extra function for lock-refresh from the main loop could fix this. But it would probably make the already ugly select-call even more ugly.

Another solution would be this:
- make sure that idle_time is not bigger than lock_refresh/2 (in mount_davfs.c, main, about line 323)
- in tidy_cache run a loop over list "changed" and refresh all locks that are going to time out.
There is already a lop over changed at the beginning of tidy_cache (it is currently only needed because the pointer in "item" might have become invalid). So this change would not seriously increase the processing time of tidy_cache. While changing this loop to care for lock-refresh it might be a good idea to split tidy_cache into several functions. Also resize_cache and minimize_mem might be better processed at the end of tidy_cache.

If you provide a patch I would also accept a different solution that solves the problem.

Cheers
Werner

- <_71007>
Wed 02 Jul 2014 03:43:13 PM UTC, original submission:  

Hi,

if davfs2 is constantly flooded with upcalls locks are not refreshed as needed.

Given a remotely located WebDAV server (ownCloud 7 instance in my case) that takes a while to respond (like in 1 sec per file) and enforces lock timeout after 300 seconds,
when I create and write to files within a loop for longer then the lock timeout, e.g. by running "for A in `seq 0 300`; do ddate > bar.$A; done"
then I would expect davfs to refresh the locks $lock_refresh seconds before they time out (approximately), i.e. after about 4 minutes

... however it doesn't do so.

Locks are only refreshed by dav_tidy_cache, which is called only if either there are no upcalls (select returns zero) or towards the end of the mainloop (however the "call again" return value isn't handled there).

Besides locks are not refreshed if davfs isn't receiving upcalls but is slowly tidying it's caches (i.e. uploading files).  Files are uploaded one by one by dav_tidy_cache; however if that process takes quite a while since there are hundreds of files in the cache, locks may time out meanwhile.

I'm not quite sure on the best way to fix, either by adding extra logic to dav_tidy_cache or by some extra loop over all held locks directly from the main loop (periodically run every $lock_refresh seconds; or faster actually).  I'd go for the latter approach since I think it's way cleaner.

I could happily provide a patch if appreciated and you agree


cheers
 ~stesie

Stefan Siegl <stesie>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by stesie (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-15 _71007 Open/ClosedOpen Closed
    2014-08-10 _71007 StatusIn Progress Done
    2014-07-06 _71007 StatusNone In Progress
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code