[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980543#action_12980543
]
Robert Muir commented on LUCENE-2793:
-------------------------------------
bq. That's how the patch works. If that doesn't look good, the other option is
placing the logic in FSDirectory and removing the FSDirectory subclasses?
We don't need to make any changes to Directory itself here, other than
openInput/createOutput taking IOContext instead of bufferSize.
The directory is the factory for opening the correct openInput/createOutput
based on its parameters, this just needs to be one.
As Mike said, the important thing is to not re-use an input that was opened
with IOContext=Merging for search.
If you ask the directory to openInput with IOContext=merging, thats all it
should be used for, because that Directory
could be implementing that with O_DIRECT or similar, which is slow for
searching.
we can muck with DirectIOLinuxDirectory later on another issue (e.g. make it a
directory wrapper that just overrides
openInput and only does something interesting when IOContext=Merging, or
NIOFSDirectory subclass, or whatever
we end up deciding).
> Directory createOutput and openInput should take an IOContext
> -------------------------------------------------------------
>
> Key: LUCENE-2793
> URL: https://issues.apache.org/jira/browse/LUCENE-2793
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Reporter: Michael McCandless
> Attachments: LUCENE-2793.patch
>
>
> Today for merging we pass down a larger readBufferSize than for searching
> because we get better performance.
> I think we should generalize this to a class (IOContext), which would hold
> the buffer size, but then could hold other flags like DIRECT (bypass OS's
> buffer cache), SEQUENTIAL, etc.
> Then, we can make the DirectIOLinuxDirectory fully usable because we would
> only use DIRECT/SEQUENTIAL during merging.
> This will require fixing how IW pools readers, so that a reader opened for
> merging is not then used for searching, and vice/versa. Really, it's only
> all the open file handles that need to be different -- we could in theory
> share del docs, norms, etc, if that were somehow possible.
--
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]
