Thank you very much, I'll try it!
On Thu, Sep 29, 2016 at 11:22 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> No ... I don't think Luke can recreate the segments file.
>
> I dug around and found the thread I was thinking of:
> http://markmail.org/thread/ayl5q6rgtngeuoyy
>
> Just be
No ... I don't think Luke can recreate the segments file.
I dug around and found the thread I was thinking of:
http://markmail.org/thread/ayl5q6rgtngeuoyy
Just be careful! Make a backup copy of your index first!
Mike McCandless
http://blog.mikemccandless.com
On Thu, Sep 29, 2016 at 11:31 AM,
do you mean `http://www.getopt.org/luke/`?
On Mon, Sep 26, 2016 at 4:58 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> It is in theory possible to reconstruct a segments file by ls-ing all
> other index files and manually rebuilding it but it is not an easy
> task and it would have
It is in theory possible to reconstruct a segments file by ls-ing all
other index files and manually rebuilding it but it is not an easy
task and it would have to make some guesses.
I think in the past a user did manage to create such a tool and maybe
posted the results here either on this list or
sorry to resend.
I'll change IO to local. Is there anyway to recover first index? now it can
not be opened by checkIndex, we are building index of 7 billion webpages,
it costs much time to rebuild.
On Sun, Sep 25, 2016 at 5:31 PM, Ziming Dong
wrote:
> I'll change IO to local. Is there anyway to
I'll change IO to local. Is there anyway to recover first index? now it can
be opened by checkIndex, we are building index of 7 billion webpages, it
costs much time to rebuild.
On Sat, Sep 24, 2016 at 2:54 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> The 'sync' option for an NFS c
The 'sync' option for an NFS client just means that every write is
sent immediately across the network. And it really is useless
performance loss as long as your app (like Lucene) does the "right
thing" with fsync.
The more important question is why fsync sent to your NFS client and
then to the M
I use the macmini on NFS server side. It seems mount option sync is
useless, just slows down the index program.
On Fri, Sep 23, 2016 at 4:43 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> OK sorry I meant your first index, and it seems to have only one
> (broken) segments file. Ca
OK sorry I meant your first index, and it seems to have only one
(broken) segments file. Can you post the "ls -l" output of that first
index? It looks like the file was (illegally) filled with 0s, or at
least the first 4 bytes were.
Lucene writes this file, fsyncs it, does an atomic rename, and
second index is recovered by checkIndex, I don't know what are in second
index directory before recover.
checkIndex can't read first index. index filenames are attached.
I use lucene6.0.0 at the beginning, then I upgrade to lucene6.1.0 to
continue index.
On Thu, Sep 22, 2016 at 10:17 PM, Michael M
Do you have 2 separate segments files in that 2nd index?
Which exact Lucene version is this?
Mike McCandless
http://blog.mikemccandless.com
On Thu, Sep 22, 2016 at 7:44 AM, Ziming Dong wrote:
> I used checkIndex to recover second index though I lost many docs in index,
> but first index can't
I used checkIndex to recover second index though I lost many docs in index,
but first index can't be read by checkIndex, error is
java -cp lucene-core-6.1.0.jar -ea:org.apache.lucene...
> org.apache.lucene.index.CheckIndex /Volumes/HPT8_56T/infomall-index/index0
> Opening index @ /Volumes/HPT8_56T
Hmm I'm no longer so sure this is an IW bug: on commit we fsync the
pending_segments_N and then do an atomic rename to segments_N.
Can you describe your IO system? Is it possible it does not implement
fsync or atomic renames correctly?
Also, your 2nd exception indices the segments_N file was int
Sorry for the slow reply here. Curious that both of these exceptions
are from IW.init. I think this may be a real bug, caused by this:
https://github.com/apache/lucene-solr/commit/981bfba841144d08df1d1a183d39fcd6f195ad56
I'll see if I can make a standalone test case showing this.
If you open th
14 matches
Mail list logo