Hi Phillipp. I couldn't find a quick fix so I recommend using the
very first patch I sent you that changes the KASSERT that was
causing the panic. I am comitting a slight variation of that patch to
current now and stable in two days.
The KASSERT was being a little too conser
I found a second issue... just a normal write-via-mmap issue, which I
think INN does. If you mmap() a file fragment and write to it via
the mmap(), m->dirty is set to VM_PAGE_BITS_ALL (0xFF). the normal buffer
flush will only clear the dirty bits on the page associated with the
fil
On Sun, Dec 10, 2000 at 02:25:48PM -0800, Matt Dillon wrote:
>
> : Hi,
> :
> :ever since this commit: ...
> :
> :dillon 2000/11/18 15:06:27 PST
> :
> : Modified files:
> :sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c
> :...
>
> When you created the filesystems on which
On Sun, Dec 10, 2000 at 03:34:32PM -0800, Matt Dillon wrote:
> :ever since this commit: ...
> :
> :dillon 2000/11/18 15:06:27 PST
> :
> : Modified files:
> :sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c
>
> Hmm. Very odd. It's catching a fully valid file page which is
Phillipp, could you do me a favor and try this patch instead of
removing the KASSERT? That is, keep the original KASSERT, apply
this patch to your -current instead, and see if you still get the
panic.
This patch is relative to -current. What it does is clear the dirty
b
:
:
: Hi,
:
:ever since this commit: ...
:
:dillon 2000/11/18 15:06:27 PST
:
: Modified files:
:sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c
Hmm. Very odd. It's catching a fully valid file page which is
marked partially dirty, less then a kilobyte in size, mappe
: Hi,
:
:ever since this commit: ...
:
:dillon 2000/11/18 15:06:27 PST
:
: Modified files:
:sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c
:...
When you created the filesystems on which the history and spool reside,
did you use any custom parameters for blocksize, fr
