[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980731#action_12980731
]
Robert Muir commented on LUCENE-2793:
-------------------------------------
bq. The proper way is to test out the things, and then move DirectIO code to
the only place it makes sense in - FSDir? Probably make it switch on/off-able,
maybe not.
I'm not sure it should be there... at least not soon. its not even something
you can implement in pure java?
we definitely have to keep it still simple and possible for people to use the
java library in a platform-indepedent way.
its also a bit dangerous, whenever JNI is involved....even if its working.
So I think its craziness, to put this direct-io stuff in fsdirectory itself.
As I said before though, i wouldn't mind if we had something more like a
'modules/native' and FSDirectory checked, if this was available and
automagically used it...
but I can't see myself thinking that we should put this logic into fsdir
itself, sorry.
bq. Sample code
My problem with your sample code is that it appears that the .setBufferSize
method is on Directory itself.
Again i disagree with this because:
* its useless to certain directories like MMapDirectory
* its dangerous in the direct-io case (different platforms have strict
requirements that things be sector-aligned etc, see the mac case where it
actually 'works' if the buffer isnt, but is just slow).
I definitely don't like the confusion regarding buffersizes now. A very small %
of the time its actually meaningful and should be respected,
but most of the time the value is completely bogus.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
