I don't think this would be any difference performance wise, and
might actually be slower.
When you call FD.sync() it only needs to ensure the dirty blocks
associated with that descriptor need to be saved.
On Nov 12, 2007, at 12:15 PM, Doug Cutting (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1044?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12541874 ]
Doug Cutting commented on LUCENE-1044:
--------------------------------------
Is a sync before every file close really needed [...] ?
It might be nice if we could use the Linux sync() system call,
instead of fsync(). Then we could call that only when the new
segments file is moved into place rather than as each file is
closed. We could exec the sync shell command when running on Unix,
but I don't know whether there's an equivalent command for Windows,
and it wouldn't be Java...
Behavior on hard power shutdown
-------------------------------
Key: LUCENE-1044
URL: https://issues.apache.org/jira/browse/
LUCENE-1044
Project: Lucene - Java
Issue Type: Bug
Components: Index
Environment: Windows Server 2003, Standard Edition, Sun
Hotspot Java 1.5
Reporter: venkat rangan
Assignee: Michael McCandless
Fix For: 2.3
Attachments: LUCENE-1044.patch, LUCENE-1044.take2.patch,
LUCENE-1044.take3.patch
When indexing a large number of documents, upon a hard power
failure (e.g. pull the power cord), the index seems to get
corrupted. We start a Java application as an Windows Service, and
feed it documents. In some cases (after an index size of 1.7GB,
with 30-40 index segment .cfs files) , the following is observed.
The 'segments' file contains only zeros. Its size is 265 bytes -
all bytes are zeros.
The 'deleted' file also contains only zeros. Its size is 85 bytes
- all bytes are zeros.
Before corruption, the segments file and deleted file appear to be
correct. After this corruption, the index is corrupted and lost.
This is a problem observed in Lucene 1.4.3. We are not able to
upgrade our customer deployments to 1.9 or later version, but
would be happy to back-port a patch, if the patch is small enough
and if this problem is already solved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
