Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <47389CC5.90501@apache.org>
Date: Mon, 12 Nov 2007 10:34:45 -0800
From: Doug Cutting <cutting@apache.org>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-1044) Behavior on hard power shutdown
References: <32259336.1194891351173.JavaMail.jira@brutus>
 <A587350A-9AB5-48AE-BEEA-5930F96B3978@ix.netcom.com>
In-Reply-To: <A587350A-9AB5-48AE-BEEA-5930F96B3978@ix.netcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

robert engels wrote:
> I don't think this would be any difference performance wise, and might 
> actually be slower.
> 
> When you call FD.sync() it only needs to ensure the dirty blocks 
> associated with that descriptor need to be saved.

The potential benefit is that you wouldn't have to wait for things to be 
written as you close files.  So, with write-behind, data could be 
written while the CPU moves on to other tasks, only blocking at commit. 
  With log-based filesystems, only the log need be flushed, and batching 
that is a performance win.  However, if there are lots of other 
applications writing at the same time, and the Lucene update is small, 
it could in theory slow things, but my hunch is that it would in 
practice frequently nearly eliminate the cost of syncing.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org