Date: Sat, 21 Jun 2003 19:35:10 +1000 From: "Tim J. Robbins" <tjr@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/ntfs ntfs_subr.c Message-ID: <20030621193510.A58194@dilbert.robbins.dropbear.id.au> In-Reply-To: <20030621135027.G51140@gamplex.bde.org>; from bde@zeta.org.au on Sat, Jun 21, 2003 at 02:58:10PM %2B1000 References: <200306201452.h5KEqqh3054891@repoman.freebsd.org> <20030621135027.G51140@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 21, 2003 at 02:58:10PM +1000, Bruce Evans wrote:
> On Fri, 20 Jun 2003, Tim J. Robbins wrote:
>
> > tjr 2003/06/20 07:52:52 PDT
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/fs/ntfs ntfs_subr.c
> > Log:
> > Merge from NetBSD src/sys/ntfs/ntfs_subr.c 1.5 & 1.30 (jdolecek):
> > - Avoid calling bread() with different sizes on the same blkno.
> > Although the buffer cache is designed to handle differing size
> > buffers, it erroneously tries to write the incorrectly-sized buffer
> > buffer back to disk before reading the correctly-sized one, even
> > when it's not dirty. This behaviour caused a panic for read-only
> > NTFS mounts when INVARIANTS was enabled ("bundirty: buffer x still
> > on queue y"), reported by NAKAJI Hiroyuki.
>
> Maybe the buffer cache is designed to handle differing size buffers in
> NetBSD, but in FreeBSD I believe it is fundamentally incompatible with
> differing size buffers except when the buffers don't overlap. The special
> case of overlap where the buffers have the same blkno could be handled
> relatively easily, but apparently isn't. The general case would involve
> searching for all overlapping buffers and updating their states coherently
> whenever a buffer is changed.
NetBSD's buffer cache definitely cannot handle requests for the same blkno
with different sizes. jdolecek added that code to avoid requesting different
sized buffers because NetBSD panics when it detects such a request; FreeBSD
tries to handle the request correctly, but does a pretty bad job of it and
issues the bogus write requests I mentioned in the commit message.
I'm still trying to figure why it tries to write non-B_DELWRI buffers back to
disk. It was added in revision 1.158, but the commit message is not very
helpful in understanding exactly what kind of problems it was trying to fix.
Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030621193510.A58194>