Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757986AbXF3LKq (ORCPT ); Sat, 30 Jun 2007 07:10:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755529AbXF3LKg (ORCPT ); Sat, 30 Jun 2007 07:10:36 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:35413 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755219AbXF3LKf (ORCPT ); Sat, 30 Jun 2007 07:10:35 -0400 Message-ID: <46863A23.2010001@garzik.org> Date: Sat, 30 Jun 2007 07:10:27 -0400 From: Jeff Garzik User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Christoph Hellwig CC: Nick Piggin , Linux Kernel Mailing List , Linux Memory Management List , linux-fsdevel@vger.kernel.org, Andrew Morton Subject: Re: [RFC] fsblock References: <20070624014528.GA17609@wotan.suse.de> <467DE00A.9080700@garzik.org> <20070630104244.GC24123@infradead.org> In-Reply-To: <20070630104244.GC24123@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 (----) X-Spam-Report: SpamAssassin version 3.1.9 on srv5.dvmed.net summary: Content analysis details: (-4.3 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1454 Lines: 33 Christoph Hellwig wrote: > On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote: >>> - In line with the above item, filesystem block allocation is performed >>> before a page is dirtied. In the buffer layer, mmap writes can dirty a >>> page with no backing blocks which is a problem if the filesystem is >>> ENOSPC (patches exist for buffer.c for this). >> This raises an eyebrow... The handling of ENOSPC prior to mmap write is >> more an ABI behavior, so I don't see how this can be fixed with internal >> changes, yet without changing behavior currently exported to userland >> (and thus affecting code based on such assumptions). > Not really, the current behaviour is a bug. And it's not actually buffer > layer specific - XFS now has a fix for that bug and it's generic enough > that everyone could use it. I'm not sure I follow. If you require block allocation at mmap(2) time, rather than when a page is actually dirtied, you are denying userspace the ability to do sparse files with mmap. A quick Google readily turns up people who have built upon the mmap-sparse-file assumption, and I don't think we want to break those assumptions as a "bug fix." Where is the bug? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/