[ https://issues.apache.org/jira/browse/LUCENE-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558406#action_12558406 ]
Grant Ingersoll commented on LUCENE-705: ---------------------------------------- This seems reasonable, although I am not an expert in low-level file system calls like this. I guess for me the thing would be to find out if the major filesystems support it (Windows, OSX, Linux) and then perhaps we can deal w/ others from there as they arise (i.e. those that don't support it) > CompoundFileWriter should pre-set its file length > ------------------------------------------------- > > Key: LUCENE-705 > URL: https://issues.apache.org/jira/browse/LUCENE-705 > Project: Lucene - Java > Issue Type: Improvement > Components: Index > Affects Versions: 2.1 > Reporter: Michael McCandless > Assignee: Michael McCandless > Priority: Minor > > I've read that if you are writing a large file, it's best to pre-set > the size of the file in advance before you write all of its contents. > This in general minimizes fragmentation and improves IO performance > against the file in the future. > I think this makes sense (intuitively) but I haven't done any real > performance testing to verify. > Java has the java.io.File.setLength() method (since 1.2) for this. > We can easily fix CompoundFileWriter to call setLength() on the file > it's writing (and add setLength() method to IndexOutput). The > CompoundFileWriter knows exactly how large its file will be. > Another good thing is: if you are going run out of disk space, then, > the setLength call should fail up front instead of failing when the > compound file is actually written. This has two benefits: first, you > find out sooner that you will run out of disk space, and, second, you > don't fill up the disk down to 0 bytes left (always a frustrating > experience!). Instead you leave what space was available > and throw an IOException. > My one hesitation here is: what if out there there exists a filesystem > that can't handle this call, and it throws an IOException on that > platform? But this is balanced against possible easy-win improvement > in performance. > Does anyone have any feedback / thoughts / experience relevant to > this? -- 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]