From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [PATCH] Fix ext2 error reporting on fsync Date: Thu, 12 Jan 2006 10:36:15 -0500 Message-ID: <200601121036.16645.mason@suse.com> References: <20060111174302.GD16728@atrey.karlin.mff.cuni.cz> <200601120858.53061.mason@suse.com> <20060112142140.GA14235@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Andrew Morton , linux-fsdevel@vger.kernel.org Return-path: Received: from ns2.suse.de ([195.135.220.15]:14988 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1751383AbWALPgV (ORCPT ); Thu, 12 Jan 2006 10:36:21 -0500 To: Jan Kara In-Reply-To: <20060112142140.GA14235@atrey.karlin.mff.cuni.cz> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thursday 12 January 2006 09:21, Jan Kara wrote: > > > Hmmm, how does this work with two concurrent fsyncs on different files? > > Where is the problem? Different files will have different buffers in > its private_list lists, different address_space structures etc. So they > should not interact in any way. Or am I missing something? > I thought ext2 was using mark_buffer_dirty_inode for the bitmap blocks as well. Checking again, it's only using it for the direct/indirect blocks. So, Andrew's idea will work fine. I suppose it's up for debate if a failure writing other metadata should fail the fsync. I would say yes, but there are valid reasons to say no. -chris