You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael Busch <bu...@gmail.com> on 2009/02/24 03:01:00 UTC
segments.gen file
Hi,
with LUCENE-1044 we sync the FS after writing files. Do we still need
the segments.gen file to handle stale caches correctly?
-Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael McCandless <lu...@mikemccandless.com>.
Super, thanks!
Mike
Danil ŢORIN wrote:
> https://issues.apache.org/jira/browse/LUCENE-1551
>
> On Mon, Mar 2, 2009 at 13:40, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> Ahh good point, that is missing. Can you open a Jira issue? Thanks.
>>
>> Mike
>>
>> Danil ŢORIN wrote:
>>
>>> I'm more interested in reopen(IndexCommit) so I could have full
>>> benefits of LUCENE-1483 (faster open, warm caches, less GC and so
>>> on)
>>> but on specific commit point.
>>>
>>> I'm not sure it's possible in current trunk, and if we have
>>> open(IndexCommit) & company, maybe we should also have similar set
>>> of
>>> methods for reopen?
>>>
>>> On Mon, Mar 2, 2009 at 12:12, Michael McCandless
>>> <lu...@mikemccandless.com> wrote:
>>>>
>>>> This is already available, as of 2.4.
>>>>
>>>> Mike
>>>>
>>>> Danil ŢORIN wrote:
>>>>
>>>>> What about opening IndexReader/Searcher on certain commit point?
>>>>> Will it be implemented in 2.9?
>>>>>
>>>>> The use-case is similar to the one Michael Busch described, only I
>>>>> would like to open (or reopen) a searcher on specific commit
>>>>> point.
>>>>>
>>>>>
>>>>> On Fri, Feb 27, 2009 at 20:31, Michael McCandless
>>>>> <lu...@mikemccandless.com> wrote:
>>>>>>
>>>>>> Michael Busch wrote:
>>>>>>
>>>>>>> Actually I personally don't need Lucene to be "write once".
>>>>>>> The reason
>>>>>>> why
>>>>>>> I started this thread about the segments.gen file was that in
>>>>>>> our
>>>>>>> project we
>>>>>>> sometimes need to rollback to a previous commit-point (using
>>>>>>> Lucene
>>>>>>> 2.4.0)
>>>>>>> that we keep around with the SnapshotDeletionPolicy. To get
>>>>>>> rid of the
>>>>>>> newest commit-point we simply delete the most recent segments
>>>>>>> file.
>>>>>>> But
>>>>>>> then
>>>>>>> we also have to delete the segments.gen file, otherwise Lucene
>>>>>>> will
>>>>>>> read
>>>>>>> the
>>>>>>> generation from it and try to find the segments file we
>>>>>>> deleted. Then
>>>>>>> Lucene
>>>>>>> will recreate the segments.gen file. This just made me think
>>>>>>> that this
>>>>>>> is
>>>>>>> not very clean (deleting and recreating the segments.gen)
>>>>>>> especially
>>>>>>> because
>>>>>>> we use a local FS and don't even need the .gen file.
>>>>>>
>>>>>> Ahh... OK. In trunk/2.9, you can explicitly open an
>>>>>> IndexWriter on a
>>>>>> prior
>>>>>> commit point, which will take care of the gen file for you.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Danil ŢORIN <to...@gmail.com>.
https://issues.apache.org/jira/browse/LUCENE-1551
On Mon, Mar 2, 2009 at 13:40, Michael McCandless
<lu...@mikemccandless.com> wrote:
>
> Ahh good point, that is missing. Can you open a Jira issue? Thanks.
>
> Mike
>
> Danil ŢORIN wrote:
>
>> I'm more interested in reopen(IndexCommit) so I could have full
>> benefits of LUCENE-1483 (faster open, warm caches, less GC and so on)
>> but on specific commit point.
>>
>> I'm not sure it's possible in current trunk, and if we have
>> open(IndexCommit) & company, maybe we should also have similar set of
>> methods for reopen?
>>
>> On Mon, Mar 2, 2009 at 12:12, Michael McCandless
>> <lu...@mikemccandless.com> wrote:
>>>
>>> This is already available, as of 2.4.
>>>
>>> Mike
>>>
>>> Danil ŢORIN wrote:
>>>
>>>> What about opening IndexReader/Searcher on certain commit point?
>>>> Will it be implemented in 2.9?
>>>>
>>>> The use-case is similar to the one Michael Busch described, only I
>>>> would like to open (or reopen) a searcher on specific commit point.
>>>>
>>>>
>>>> On Fri, Feb 27, 2009 at 20:31, Michael McCandless
>>>> <lu...@mikemccandless.com> wrote:
>>>>>
>>>>> Michael Busch wrote:
>>>>>
>>>>>> Actually I personally don't need Lucene to be "write once". The reason
>>>>>> why
>>>>>> I started this thread about the segments.gen file was that in our
>>>>>> project we
>>>>>> sometimes need to rollback to a previous commit-point (using Lucene
>>>>>> 2.4.0)
>>>>>> that we keep around with the SnapshotDeletionPolicy. To get rid of the
>>>>>> newest commit-point we simply delete the most recent segments file.
>>>>>> But
>>>>>> then
>>>>>> we also have to delete the segments.gen file, otherwise Lucene will
>>>>>> read
>>>>>> the
>>>>>> generation from it and try to find the segments file we deleted. Then
>>>>>> Lucene
>>>>>> will recreate the segments.gen file. This just made me think that this
>>>>>> is
>>>>>> not very clean (deleting and recreating the segments.gen) especially
>>>>>> because
>>>>>> we use a local FS and don't even need the .gen file.
>>>>>
>>>>> Ahh... OK. In trunk/2.9, you can explicitly open an IndexWriter on a
>>>>> prior
>>>>> commit point, which will take care of the gen file for you.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael McCandless <lu...@mikemccandless.com>.
Ahh good point, that is missing. Can you open a Jira issue? Thanks.
Mike
Danil ŢORIN wrote:
> I'm more interested in reopen(IndexCommit) so I could have full
> benefits of LUCENE-1483 (faster open, warm caches, less GC and so on)
> but on specific commit point.
>
> I'm not sure it's possible in current trunk, and if we have
> open(IndexCommit) & company, maybe we should also have similar set of
> methods for reopen?
>
> On Mon, Mar 2, 2009 at 12:12, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> This is already available, as of 2.4.
>>
>> Mike
>>
>> Danil ŢORIN wrote:
>>
>>> What about opening IndexReader/Searcher on certain commit point?
>>> Will it be implemented in 2.9?
>>>
>>> The use-case is similar to the one Michael Busch described, only I
>>> would like to open (or reopen) a searcher on specific commit point.
>>>
>>>
>>> On Fri, Feb 27, 2009 at 20:31, Michael McCandless
>>> <lu...@mikemccandless.com> wrote:
>>>>
>>>> Michael Busch wrote:
>>>>
>>>>> Actually I personally don't need Lucene to be "write once". The
>>>>> reason
>>>>> why
>>>>> I started this thread about the segments.gen file was that in our
>>>>> project we
>>>>> sometimes need to rollback to a previous commit-point (using
>>>>> Lucene
>>>>> 2.4.0)
>>>>> that we keep around with the SnapshotDeletionPolicy. To get rid
>>>>> of the
>>>>> newest commit-point we simply delete the most recent segments
>>>>> file. But
>>>>> then
>>>>> we also have to delete the segments.gen file, otherwise Lucene
>>>>> will read
>>>>> the
>>>>> generation from it and try to find the segments file we deleted.
>>>>> Then
>>>>> Lucene
>>>>> will recreate the segments.gen file. This just made me think
>>>>> that this
>>>>> is
>>>>> not very clean (deleting and recreating the segments.gen)
>>>>> especially
>>>>> because
>>>>> we use a local FS and don't even need the .gen file.
>>>>
>>>> Ahh... OK. In trunk/2.9, you can explicitly open an IndexWriter
>>>> on a
>>>> prior
>>>> commit point, which will take care of the gen file for you.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Danil ŢORIN <to...@gmail.com>.
I'm more interested in reopen(IndexCommit) so I could have full
benefits of LUCENE-1483 (faster open, warm caches, less GC and so on)
but on specific commit point.
I'm not sure it's possible in current trunk, and if we have
open(IndexCommit) & company, maybe we should also have similar set of
methods for reopen?
On Mon, Mar 2, 2009 at 12:12, Michael McCandless
<lu...@mikemccandless.com> wrote:
>
> This is already available, as of 2.4.
>
> Mike
>
> Danil ŢORIN wrote:
>
>> What about opening IndexReader/Searcher on certain commit point?
>> Will it be implemented in 2.9?
>>
>> The use-case is similar to the one Michael Busch described, only I
>> would like to open (or reopen) a searcher on specific commit point.
>>
>>
>> On Fri, Feb 27, 2009 at 20:31, Michael McCandless
>> <lu...@mikemccandless.com> wrote:
>>>
>>> Michael Busch wrote:
>>>
>>>> Actually I personally don't need Lucene to be "write once". The reason
>>>> why
>>>> I started this thread about the segments.gen file was that in our
>>>> project we
>>>> sometimes need to rollback to a previous commit-point (using Lucene
>>>> 2.4.0)
>>>> that we keep around with the SnapshotDeletionPolicy. To get rid of the
>>>> newest commit-point we simply delete the most recent segments file. But
>>>> then
>>>> we also have to delete the segments.gen file, otherwise Lucene will read
>>>> the
>>>> generation from it and try to find the segments file we deleted. Then
>>>> Lucene
>>>> will recreate the segments.gen file. This just made me think that this
>>>> is
>>>> not very clean (deleting and recreating the segments.gen) especially
>>>> because
>>>> we use a local FS and don't even need the .gen file.
>>>
>>> Ahh... OK. In trunk/2.9, you can explicitly open an IndexWriter on a
>>> prior
>>> commit point, which will take care of the gen file for you.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael McCandless <lu...@mikemccandless.com>.
This is already available, as of 2.4.
Mike
Danil ŢORIN wrote:
> What about opening IndexReader/Searcher on certain commit point?
> Will it be implemented in 2.9?
>
> The use-case is similar to the one Michael Busch described, only I
> would like to open (or reopen) a searcher on specific commit point.
>
>
> On Fri, Feb 27, 2009 at 20:31, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> Michael Busch wrote:
>>
>>> Actually I personally don't need Lucene to be "write once". The
>>> reason why
>>> I started this thread about the segments.gen file was that in our
>>> project we
>>> sometimes need to rollback to a previous commit-point (using
>>> Lucene 2.4.0)
>>> that we keep around with the SnapshotDeletionPolicy. To get rid of
>>> the
>>> newest commit-point we simply delete the most recent segments
>>> file. But then
>>> we also have to delete the segments.gen file, otherwise Lucene
>>> will read the
>>> generation from it and try to find the segments file we deleted.
>>> Then Lucene
>>> will recreate the segments.gen file. This just made me think that
>>> this is
>>> not very clean (deleting and recreating the segments.gen)
>>> especially because
>>> we use a local FS and don't even need the .gen file.
>>
>> Ahh... OK. In trunk/2.9, you can explicitly open an IndexWriter on
>> a prior
>> commit point, which will take care of the gen file for you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Danil ŢORIN <to...@gmail.com>.
What about opening IndexReader/Searcher on certain commit point?
Will it be implemented in 2.9?
The use-case is similar to the one Michael Busch described, only I
would like to open (or reopen) a searcher on specific commit point.
On Fri, Feb 27, 2009 at 20:31, Michael McCandless
<lu...@mikemccandless.com> wrote:
>
> Michael Busch wrote:
>
>> Actually I personally don't need Lucene to be "write once". The reason why
>> I started this thread about the segments.gen file was that in our project we
>> sometimes need to rollback to a previous commit-point (using Lucene 2.4.0)
>> that we keep around with the SnapshotDeletionPolicy. To get rid of the
>> newest commit-point we simply delete the most recent segments file. But then
>> we also have to delete the segments.gen file, otherwise Lucene will read the
>> generation from it and try to find the segments file we deleted. Then Lucene
>> will recreate the segments.gen file. This just made me think that this is
>> not very clean (deleting and recreating the segments.gen) especially because
>> we use a local FS and don't even need the .gen file.
>
> Ahh... OK. In trunk/2.9, you can explicitly open an IndexWriter on a prior
> commit point, which will take care of the gen file for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael McCandless <lu...@mikemccandless.com>.
Michael Busch wrote:
> On 2/26/09 1:50 PM, Michael McCandless wrote:
>>
>> Michael Busch wrote:
>>
>>> On 2/24/09 4:05 AM, Michael McCandless wrote:
>>>>
>>>> I believe we still need this, for remote filesystems (like NFS)
>>>> that have inconsistent client-side caching.
>>>>
>>>> The fsync() ensures the local IO system has moved the bytes/file
>>>> metadata to stable storage, but I'd expect remote caches would
>>>> still potentially be stale.
>>>>
>>>
>>> We could have an expert API to turn using the .gen file on/off?
>>> And then default it to off in 3.0.
>>
>> We could do that, though I'd default to leaving it on?
>
> I said off, because I think most people don't use NFS (and we don't
> even recommend using it for performance reasons). But defaulting to
> on would be ok too, to be on the safe side.
OK. I'm not certain other filesystems aren't affected, so being
defensive seems best...
>>> I think the .gen file and the CompoundFileWriter are the only
>>> places left where we overwrite (parts of) files? To change the
>>> latter we could move the cfs header to the segments file.
>>
>>
>> TermInfosWriter also seeks & writes a header; see here (enabling
>> Lucene to write directly to HDFS):
>>
>> http://issues.apache.org/jira/browse/LUCENE-532
>>
>> What situation are you seeing that requires absolute "write once"?
>>
> Actually I personally don't need Lucene to be "write once". The
> reason why I started this thread about the segments.gen file was
> that in our project we sometimes need to rollback to a previous
> commit-point (using Lucene 2.4.0) that we keep around with the
> SnapshotDeletionPolicy. To get rid of the newest commit-point we
> simply delete the most recent segments file. But then we also have
> to delete the segments.gen file, otherwise Lucene will read the
> generation from it and try to find the segments file we deleted.
> Then Lucene will recreate the segments.gen file. This just made me
> think that this is not very clean (deleting and recreating the
> segments.gen) especially because we use a local FS and don't even
> need the .gen file.
Ahh... OK. In trunk/2.9, you can explicitly open an IndexWriter on a
prior commit point, which will take care of the gen file for you.
> I mentioned the "write once" issue because I think with disabling
> the .gen file and all your recent changes (especially lockless
> commits) we've almost accomplished "write once", so we might as well
> change the last two places that don't comply (CFSWriter and
> TermInfosWriter), to resolve LUCENE-532. Not sure how many user
> there are out there who really need it though.
OK. Writing an index to HDFS is the only "real" case I know about so
far... would be curious if there are others.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael Busch <bu...@gmail.com>.
On 2/26/09 1:50 PM, Michael McCandless wrote:
>
> Michael Busch wrote:
>
>> On 2/24/09 4:05 AM, Michael McCandless wrote:
>>>
>>> I believe we still need this, for remote filesystems (like NFS) that
>>> have inconsistent client-side caching.
>>>
>>> The fsync() ensures the local IO system has moved the bytes/file
>>> metadata to stable storage, but I'd expect remote caches would still
>>> potentially be stale.
>>>
>>
>> We could have an expert API to turn using the .gen file on/off? And
>> then default it to off in 3.0.
>
> We could do that, though I'd default to leaving it on?
I said off, because I think most people don't use NFS (and we don't even
recommend using it for performance reasons). But defaulting to on would
be ok too, to be on the safe side.
>
>> I think the .gen file and the CompoundFileWriter are the only places
>> left where we overwrite (parts of) files? To change the latter we
>> could move the cfs header to the segments file.
>
>
> TermInfosWriter also seeks & writes a header; see here (enabling
> Lucene to write directly to HDFS):
>
> http://issues.apache.org/jira/browse/LUCENE-532
>
> What situation are you seeing that requires absolute "write once"?
>
Actually I personally don't need Lucene to be "write once". The reason
why I started this thread about the segments.gen file was that in our
project we sometimes need to rollback to a previous commit-point (using
Lucene 2.4.0) that we keep around with the SnapshotDeletionPolicy. To
get rid of the newest commit-point we simply delete the most recent
segments file. But then we also have to delete the segments.gen file,
otherwise Lucene will read the generation from it and try to find the
segments file we deleted. Then Lucene will recreate the segments.gen
file. This just made me think that this is not very clean (deleting and
recreating the segments.gen) especially because we use a local FS and
don't even need the .gen file.
I mentioned the "write once" issue because I think with disabling the
.gen file and all your recent changes (especially lockless commits)
we've almost accomplished "write once", so we might as well change the
last two places that don't comply (CFSWriter and TermInfosWriter), to
resolve LUCENE-532. Not sure how many user there are out there who
really need it though.
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael McCandless <lu...@mikemccandless.com>.
Michael Busch wrote:
> On 2/24/09 4:05 AM, Michael McCandless wrote:
>>
>> I believe we still need this, for remote filesystems (like NFS)
>> that have inconsistent client-side caching.
>>
>> The fsync() ensures the local IO system has moved the bytes/file
>> metadata to stable storage, but I'd expect remote caches would
>> still potentially be stale.
>>
>
> We could have an expert API to turn using the .gen file on/off? And
> then default it to off in 3.0.
We could do that, though I'd default to leaving it on?
> I think the .gen file and the CompoundFileWriter are the only places
> left where we overwrite (parts of) files? To change the latter we
> could move the cfs header to the segments file.
TermInfosWriter also seeks & writes a header; see here (enabling
Lucene to write directly to HDFS):
http://issues.apache.org/jira/browse/LUCENE-532
What situation are you seeing that requires absolute "write once"?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael Busch <bu...@gmail.com>.
On 2/24/09 4:05 AM, Michael McCandless wrote:
>
> I believe we still need this, for remote filesystems (like NFS) that
> have inconsistent client-side caching.
>
> The fsync() ensures the local IO system has moved the bytes/file
> metadata to stable storage, but I'd expect remote caches would still
> potentially be stale.
>
We could have an expert API to turn using the .gen file on/off? And then
default it to off in 3.0.
I think the .gen file and the CompoundFileWriter are the only places
left where we overwrite (parts of) files? To change the latter we could
move the cfs header to the segments file.
-Michael
> Mike
>
> Michael Busch wrote:
>
>> Hi,
>>
>> with LUCENE-1044 we sync the FS after writing files. Do we still need
>> the segments.gen file to handle stale caches correctly?
>>
>> -Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: segments.gen file
Posted by Michael McCandless <lu...@mikemccandless.com>.
I believe we still need this, for remote filesystems (like NFS) that
have inconsistent client-side caching.
The fsync() ensures the local IO system has moved the bytes/file
metadata to stable storage, but I'd expect remote caches would still
potentially be stale.
Mike
Michael Busch wrote:
> Hi,
>
> with LUCENE-1044 we sync the FS after writing files. Do we still
> need the segments.gen file to handle stale caches correctly?
>
> -Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org