[ome-users] Binary repo on NFS (was: import error)
josh at glencoesoftware.com
Wed Jan 30 07:54:21 GMT 2013
On Jan 25, 2013, at 10:50 AM, Niko Ehrenfeuchter wrote:
> On 23.01.2013 22:09, Josh Moore wrote:
>> On Jan 23, 2013, at 7:42 PM, Damir Sudar wrote:
>>> Hi Josh,
>> Hi Damir,
>> my apologies for letting this slip. Please do try to CC ome-users
>> since the rest of the team won't let me forget! :)
>>> Based on your initial question about what filesystem, I looked a
>>> little further and tried to import the same offending file into a
>>> different OMERO installation that we set up for testing. This test
>>> installation is also on Ubuntu 12.04LTS but uses a xfs Linux
>>> filesystem for the omero.data.dir. And that one had no trouble with
>>> the offending file. Have you seen others have trouble with using a
>>> CIFS filesystem?
>> NFS & Samba filesystems have all shown problems in some if not most
>> cases. The base requirement is that the posix locking semantics are
>> guaranteed. A couple other threads on this topic:
> picking up this thread in regard to the message you're quoting here - apparently the launching of "nfslockd" hasn't been integrated into the startup scripts yet. Is that correct?
> Josh, as you wrote in the pull request it would be very helpful to have a test to check locking. This is extremely important for us as we're currently forced to have the binary repository on NFS :-(
> So the basic questions that currently come to my mind are:
> - what specific variant(s) of locking need to be supported (flock(), fcntl(), lockf()), do you have any references that I can feed to our storage-experts?
> - why is locking done, for multi-threading or multi-nodes (or ...)?
> - do you expect that running "nfslockd" is sufficient?
> - how can we check if it is working correctly?
> - is NFSv4 instead of v3 something that could help?
> Thanks a lot!
Thanks for the feeback, Niko! I added your comments to https://github.com/openmicroscopy/ome-documentation/pull/227
More information about the ome-users