From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 15:08:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AAB816A41F; Mon, 31 Oct 2005 15:08:43 +0000 (GMT) (envelope-from gemini@geminix.org) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF77143D48; Mon, 31 Oct 2005 15:08:42 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <4366336E.8070601@geminix.org> Date: Mon, 31 Oct 2005 16:08:30 +0100 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051029 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Konovalov References: <2b22951e0510302128q571a3c1se111262e88ae19bb@mail.gmail.com> <20051031144056.A92356@mp2.macomnet.net> <20051031162438.I554@is.park.rambler.ru> <20051031170805.T94695@mp2.macomnet.net> In-Reply-To: <20051031170805.T94695@mp2.macomnet.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWbGx-0001Um-My; Mon, 31 Oct 2005 16:08:31 +0100 X-Mailman-Approved-At: Tue, 01 Nov 2005 13:15:03 +0000 Cc: Edwin Groothuis , Igor Sysoev , bug-followup@freebsd.org, "Cai, Quanqing" , freebsd-current@freebsd.org Subject: Re: kern/67919: Why nobody take serious to fix this bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 15:08:43 -0000 Maxim Konovalov wrote: > [...] > >>>I was told the patch is incorrect. It works in certain cases but >>>incorrect in general. >> >>Why is it incorrect ? I'm using it for year. > > Because you can't just throw away any chunk of data (e.g. it could be > a meta-data) without a risk to damage a filesystem. I wonder, could it really be meta-data? I was under the impression that meta-data is a filesystem property and is therefore dealt with in the filesystem code, through i/o buffers. Isn't the VM pager responsible for handling object contents (files etc.), only? If so, it would be unfortunate to throw away pages of data but it certainly wouldn't damage the filesystem. As to our own experience: Since I provided the patch a year ago or so we've had tons of users bumping against the space limit of their respective disk containers (with the VM pager involved: Berkeley DB 3, for instance) but not a single instance where the filesystem had been damaged by this incident. This is on the 4.x branch. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net