From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: Does fsync() block read and write ops on the same file? Date: Fri, 11 Dec 2009 08:53:37 +0000 Message-ID: <82hbrxhoxa.fsf@mid.bfk.de> References: <82ein3npyc.fsf@mid.bfk.de> <20091211035521.GI30608@discord.disaster> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from mx01.bfk.de ([193.227.124.2]:37957 "EHLO mx01.bfk.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752984AbZLKIxd convert rfc822-to-8bit (ORCPT ); Fri, 11 Dec 2009 03:53:33 -0500 In-Reply-To: <20091211035521.GI30608@discord.disaster> (Dave Chinner's message of "Fri\, 11 Dec 2009 14\:55\:21 +1100") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: * Dave Chinner: > On Thu, Dec 10, 2009 at 09:22:35AM +0000, Florian Weimer wrote: >> I've got an odd performance issue. It seems that when fsync() is >> called on a file, other processes block when they try to access it. >> This is not merely due to I/O contention on the underlying block >> device, it seems. > > The inode mutex is held across the ->fsync() method. If that takes a > long time to run, then other processes will block trying to take the > inode mutex. i.e. part of fsync serialises access to the inode. Is an inode lock required to read from the file? >> Oracle reported a similar performance issue in the Berkeley DB JE >> changelog. Is this really true? Are there any workarounds? (I'm >> mainly interested in the situation on ext[34] and XFS.) > > For XFS, the ->fsync method blocks for as long as it takes to write > a synchronous transaction (1 IO). ext4 looks like it writes the > inode rather than doing a journal commit, so it should only need a > single IO with the inode mutex held, too. I don't think these can be > optimised any further. I'm not concerned with fsync latency per se. It's going to take a while to write a few GBs scattered across the file. However, it's annoying that read operations on the same file (which can't even see the effect of the fsync operation) are blocked, some times for more than two minutes. --=20 =46lorian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html