[ome-devel] Trouble with OMERO.Dropbox

Niko Ehrenfeuchter nikolaus.ehrenfeuchter at unibas.ch
Thu Feb 5 10:45:59 GMT 2015


Hi Colin,

On 05.02.2015 11:28, Colin Blackburn wrote:
> Hi Niko,
>
>> I finally managed to do so, log files were uploaded in QA ticket
>> 10456.
>
> Thanks.
>
>> The relevant part in those logs is from January 29th, copying a
>> large Leica LIF file (~32 GB), probably containing a multi-position
>> timelapse. I can ask for more details if this is important (or
>> provide the file).
>
> The same effect is occurring with the two smaller LSM files following
> this LIF file copy, though with a smaller impact on the logging. The
> underlying events are being produced by the inotify system so if this
> is a new effect might something have changed with your OS/filesystem?
> I assume from the logs that the imports are then proceeding as
> normal?

This is not new, there were no changes done to the system. It is just 
that smaller files have a much less serious impact on the system.

Although I have to say that we've previously seen it stall for pretty 
long periods (30-120 minutes) when many (~15-20) people copied several 
smaller files to the DropBox at the same time.

Most of the files get imported correctly at the end, but I wouldn't 
place a bet on the very large ones. However, we've seen system load 
going up to more than 50 (!), rendering the whole machine basically dead.

> One thing we could certainly fix at our end is to reduce much of this
> logging to DEBUG level, though I don’t know how much impact that
> would have on cpu usage. But if you were happy to patch your code I
> could make this available for testing.

Sure, we'd love to try this. In the current situation, DropBox is 
entirely unusable for our scenario :-(

> It is also possible, again via a change in our codebase, to not
> actively ask for modify events, however if a create event is missed
> for a file (notification systems aren’t perfect) then first modify
> event for a file serves in lieu of a create. This would be a more
> significant change that would require more extensive testing from
> us.

Is there no way to configure the behaviour of the inotify subsystem to 
trigger (or pass on) modification with a lower frequency, e.g. only once 
per second instead of once per millisecond?

Cheers,
~Niko


More information about the ome-devel mailing list