Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 865 invoked from network); 3 Dec 2010 09:29:36 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Dec 2010 09:29:36 -0000 Received: (qmail 56966 invoked by uid 500); 3 Dec 2010 09:29:35 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 56843 invoked by uid 500); 3 Dec 2010 09:29:35 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 56836 invoked by uid 99); 3 Dec 2010 09:29:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Dec 2010 09:29:34 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Dec 2010 09:29:32 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id oB39TB0Y023015 for ; Fri, 3 Dec 2010 09:29:11 GMT Message-ID: <28398500.90851291368551049.JavaMail.jira@thor> Date: Fri, 3 Dec 2010 04:29:11 -0500 (EST) From: "Michael McCandless (JIRA)" To: dev@lucene.apache.org Subject: [jira] Commented: (LUCENE-2791) WindowsDirectory In-Reply-To: <22607233.86291291338491348.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966459#action_12966459 ] Michael McCandless commented on LUCENE-2791: -------------------------------------------- This is awesome! It gives us a workaround to the JRE bug (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734) killing NIOFSDir's concurrency on Windows. Does is also allow for deletion of still-open files? You may want to experiment w/ different buffer sizes to see if that impacts performance. Also: this allows you to do the equivalent of Linux's O_DIRECT, right? If so... I think we should augment the Dir API so that on opening an input it receives some sort of IOContext or something expressing why we are opening. So for merging we would want "direct iO" (bypass OS buffer cache or NOREUSE fadvise flag, etc.), and larger buffer sizes and perhaps other low level IO settings in the future. > WindowsDirectory > ---------------- > > Key: LUCENE-2791 > URL: https://issues.apache.org/jira/browse/LUCENE-2791 > Project: Lucene - Java > Issue Type: New Feature > Components: Store > Reporter: Robert Muir > Attachments: LUCENE-2791.patch, LUCENE-2791.patch, WindowsDirectory.dll, WindowsDirectory_amd64.dll > > > We can use Windows' overlapped IO to do pread() and avoid the performance problems of SimpleFS/NIOFSDir. -- 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-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org