[ 
https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731118#action_12731118
 ] 

Uwe Schindler commented on LUCENE-1743:
---------------------------------------

Another idea to think about:
Maybe we make the base FSDirectory configureable, that you can define rules for 
the IndexInput or IndexOutput instances used. Why create three directories, 
when you could only use on that just decides, what is the right 
IndexInput/IndexOutput? In this case you need no MMapDirectory, no NIOFSDir, no 
SimpleFSDir. The basic list files, rename and so on are always identical (for 
FSDirs). The only difference is the IndexInput and IndexOutput.

In this case you would only have *one* LockFactory, which would be good in my 
opinion (see above).

So we only provide the Input/Output classes as separate top-level classes: 
SimpleFSIndexInput, MMapIndexInput (internal two classes for chunking or not), 
NIOIndexInput and for output at the beginning only the current 
SimpleFSIndexOutput. You can then configure your FSDirectory to use different 
impls depending on an method or rule defined like above. For backwards 
compatibility, the current MMapDirectory and so on are simple subclasses of 
this universal FSDir with a fixed configuration.

FileSwitchDirectory should only used, when you really want to separate two 
directories in complete (stored fields on disk, index on SSD in two physical 
different dirs).

> MMapDirectory should only mmap large files, small files should be opened 
> using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1743
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a 
> file into memory is more expensive than reading or writing a few tens of 
> kilobytes of data via the usual read and write methods. From the standpoint 
> of performance it is generally only worth mapping relatively large files into 
> memory."
> MMapDirectory should get a user-configureable size parameter that is a lower 
> limit for mmapping files. All files with a size<limit should be opened using 
> a conventional IndexInput from SimpleFS or NIO (another configuration option 
> for the fallback?).

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to