From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 10/11] hfsplus: optimize fsync Date: Mon, 22 Nov 2010 14:29:59 +0100 Message-ID: <20101122132959.GA7459@lst.de> References: <20101117222117.GA21700@lst.de> <20101117222313.GK21700@lst.de> <20101118135047.GA14669@lst.de> <20101118141657.GA16690@lst.de> <20101122130314.GB12716@amd> <20101122131808.GA12831@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Nick Piggin , linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Received: from verein.lst.de ([213.95.11.210]:45622 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754782Ab0KVNaD (ORCPT ); Mon, 22 Nov 2010 08:30:03 -0500 Content-Disposition: inline In-Reply-To: <20101122131808.GA12831@amd> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Nov 23, 2010 at 12:18:08AM +1100, Nick Piggin wrote: > Actually now I look at your updated patch, perhaps it is not. What > version does that patch apply against? Do you have a tree or tarball > uploaded anywhere? Or can you repost the full series? It applies instead of the previous patch in that series, that is after the 9 patches before it. I don't think hfsplus has issue you mentioned in that other thread, not by design but more by accident due to: - not checking the dirty bits anymore as it doesn't implement the fdatasync optimization. - hfsplus_write_inode first calling hfsplus_ext_write_extent before setting the catalog dirty bit, with hfsplus_ext_write_extent always locking and unlocking a mutex and thus providing the required memory barrier.