From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] Fix ext2 error reporting on fsync Date: Thu, 19 Jan 2006 13:16:48 -0800 Message-ID: <20060119131648.68d7c6eb.akpm@osdl.org> References: <20060111174302.GD16728@atrey.karlin.mff.cuni.cz> <20060112142656.GB14235@atrey.karlin.mff.cuni.cz> <20060112124717.6e242802.akpm@osdl.org> <200601122108.55103.mason@suse.com> <20060112181628.63c4bf39.akpm@osdl.org> <20060118224652.GA6434@atrey.karlin.mff.cuni.cz> <20060118150646.7514ba5f.akpm@osdl.org> <20060119122125.GA12563@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mason@suse.com, linux-fsdevel@vger.kernel.org Return-path: Received: from smtp.osdl.org ([65.172.181.4]:47592 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1161431AbWASVRe (ORCPT ); Thu, 19 Jan 2006 16:17:34 -0500 To: Jan Kara In-Reply-To: <20060119122125.GA12563@atrey.karlin.mff.cuni.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jan Kara wrote: > > > (If you're proposing that we walk the buffer_head list until we somehow > > find the list_head or hlist_head which is embedded within the desired > > address_space then yes2, but how do we know where to terminate the search?) > Yes, that's it. If the list is not circular, then it's easy to find > it's head. So what I suggest is to change private_list from a circular > list of list_head structures to the non-circular one. And because > non-circular list is already implemented in hlist macros I'd simply use > those. The only minor hack is that mapping would not contain hlist_head > but hlist_node with pprev set to NULL so that we easily recognize it when > traversing backwards. Is it clearer now? Ah, yes. It could get pretty inefficient in some corner cases, I guess. A 4GB file will have up to 1000 buffers on that list so we're looking at potentially O(1000000) operations. Plan B is to stick with a doubly-linked list, but mark the address_space's list_head by setting bit 0 of its list_head.next to 1. The challenge is to implement this in a manner which Linus doesn't notice ;)