[Edserplo_users] IT report-Edserplo saving (alga387652)

[Steve Loch]

Alex 

30-odd MB is big in these circumstances and we have observed these problems in the past. All saving of such files takes a long time over the network and the problem has been with us for over 20 years! It certainly has applied to Serplo and Xerplo. Samrat did some work on this and we cached a copy of the file locally (see the interface reference below). We then used a sequential transfer to achieve the update at the end of processing.

We involved iTSS in the issue too and they pointed out there was a local setting in Samba which slowed down random IO too. Quite where we are with that I'm not sure. We had a test mounting point and it proved faster but whether the adjustment was subsequently made to the L: drive I am not sure.  BODCBigRandomAccess is the interface specifying the caching capability and that's enabled for QXF and if we are using that then Samba issue is probably irrelevant.

Steve  

>>> "Malcolm Hearn" <malh at bodc.ac.uk> 17/02/2006 12:35:48 >>>
Rashid

The following has been logged as high priority

Mal


>>> Alex Gardiner 17/02/06 12:20:17 >>>
Hi Mal,

I'm having problems saving underway qxf files with Edserplo. It just seems to hang when I click exit and then save updates before quitting. I have to close it down by closing down the edserplo error reporting window.  It could of course just be a matter of waiting longer as I have corrupted a qxf by closing edserplo down too early whereas the edits were saved when I waited a bit longer before "forcing" a close (might be useful to have a progress report when saving  a file, eg. % complete??).

The file I've been using is /users/odb/d286/uway/d286.qxf and I would say it's medium/high priority.

Thanks,

Alex


_______________________________________________
Edserplo_users mailing list
Edserplo_users at biwebs1.nerc-liv.ac.uk 
http://mailman.nerc-liv.ac.uk/mailman/listinfo/edserplo_users