Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NFS weirdness...



How are the Lucene Index directories being exported, and what parameters =

are you using to mount. This looks to me like more of a networking issue.=

Make sure your switch/router is solid. I did a quick google search of=20
=2Enfs files since I wanted to present a better answer.
http://opensolaris.org/jive/thread.jspa?threadID=3D84407&tstart=3D0
".nfs files are created when a file is deleted that is still open. "

The above URL refers to Solaris, and is not 100% relevant. You can also=20
use the lsof command to see if it refers to any open file.

My thoughts are (1. network flakyness, 2. the a program dies before=20
properly closing the nfs file.

Since it appears that the Lucene Indexes are not modified, you probably=20
should export those directories read-only if you don't know.

On 04/16/2009 01:14 PM, ref wrote:
> Hi,
>
> I am using NFS in a production environment to allow multiple front end
> servers to access a data server containing Lucene indexes.
> Recently, the NFS connections have been acting weird and the index file=
s
> got badly corrupted. While investigating, I saw a load of zero byte
> files in the NFS mounted directory ...  Is this normal ? what are these=

> files ? can I bit-bucket them ? are they important ? I have not seen
> them before/become aware of them till now ...
>
>
> -rw-rw-r--  1 production production     0 Apr 15
> 14:09 .nfs016007720001e150
> -rw-rw-r--  1 production production     0 Apr 15
> 16:10 .nfs016007ea0001e270
> -rw-rw-r--  1 production production     0 Apr 16
> 06:11 .nfs016008e20001e742
> -rw-rw-r--  1 production production     0 Apr 16
> 04:11 .nfs016009a80001e6bc
> -rw-rw-r--  1 production production     0 Apr 15
> 16:10 .nfs01600a270001e246
> -rw-rw-r--  1 production production     0 Apr 16
> 10:09 .nfs01600a560001e85e
> -rw-rw-r--  1 production production     0 Apr 15
> 14:09 .nfs01600a790001e14f
> -rw-rw-r--  1 production production     0 Apr 15
> 14:09 .nfs01600a860001e151
> -rw-rw-r--  1 production production     0 Apr 15
>
>
> any help most welcome (rebuilding lucene indexes is a time consuming
> process and I'd rather not have to do it regularly!)
>
> thanks,
>
> Richard
>  =20


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org