robert engels wrote:
It would appear that NFS Version 2 is not suitable for Lucene. NFS
Version 3 looks like it should work. See
http://nfs.sourceforge.net/#section_a
I will take this opportunity to state again what I've always been told,
and it seems to hold up, using NFS for shared interactively updated
files is always going to be troublesome. They have patched it over the
years to help, but it just wasn't designed for this for the beginning.
Unix systems never even had file system locks. It was assumed that
shared access to shared data would be accomplished via a shared server -
not by sharing access to the data directly. It is far more efficient and
robust to do things this way.
Modifying a shared Lucene directory via NFS directly is always going to
be error prone.
Why not just implement a server/parallel index solution ?
Actually I think now (with lockless commits) Lucene works fine over
NFS, except for the [yes, rather big] remaining issue: LUCENE-710.
But that issue, while clearly scary when you first see it, can be
easily worked around (just refresh your searchers once they hit "Stale
NFS handle").
Even once we resolve that and Lucene works over NFS, I do think the
performance will typically not be "stellar". At least in my
experience the performance of NFS is surprisingly poor. So I do think
for users that require high performance a replicated (like Solr)
and/or distributed index solution is probably the way to go.
Anyway, I didn't mean to turn this back into an NFS discussion. I
just wanted to use NFS as an example of where relying on file length
for something important (maxDocs() in a segment) is possibly
dangerous.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
