kern/67919: Why nobody take serious to fix this bug?

[Uwe Doering]

The following reply was made to PR kern/67919; it has been noted by GNATS.

From: Uwe Doering <gemini at geminix.org>
To: Maxim Konovalov <maxim at macomnet.ru>
Cc: Igor Sysoev <is at rambler-co.ru>, 
 "Cai, Quanqing" <caiquanqing at gmail.com>,
  freebsd-current at freebsd.org,  bug-followup at freebsd.org, 
 Edwin Groothuis <edwin at mavetju.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Mon, 31 Oct 2005 16:08:30 +0100

 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 at geminix.org  |  http://www.escapebox.net