Date: Mon, 31 Oct 2005 16:08:30 +0100 From: Uwe Doering <gemini@geminix.org> To: Maxim Konovalov <maxim@macomnet.ru> Cc: Edwin Groothuis <edwin@mavetju.org>, Igor Sysoev <is@rambler-co.ru>, bug-followup@freebsd.org, "Cai, Quanqing" <caiquanqing@gmail.com>, freebsd-current@freebsd.org Subject: Re: kern/67919: Why nobody take serious to fix this bug? Message-ID: <4366336E.8070601@geminix.org> In-Reply-To: <20051031170805.T94695@mp2.macomnet.net> References: <2b22951e0510302128q571a3c1se111262e88ae19bb@mail.gmail.com> <20051031144056.A92356@mp2.macomnet.net> <20051031162438.I554@is.park.rambler.ru> <20051031170805.T94695@mp2.macomnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4366336E.8070601>