Brad Knowles wrote:
> At 8:12 PM +0800 1999/12/28, Peter Wemm wrote:
>
> > FYI for the list; this has been fixed and committed now. Another problem
> > in vn when backed with swap was found and fixed too.
>
> Was the vn problem an issue for 3.x as well? If so, is there any
> chance of
At 8:12 PM +0800 1999/12/28, Peter Wemm wrote:
> FYI for the list; this has been fixed and committed now. Another problem
> in vn when backed with swap was found and fixed too.
Was the vn problem an issue for 3.x as well? If so, is there any
chance of getting this mfc'ed any time so
FYI for the list; this has been fixed and committed now. Another problem
in vn when backed with swap was found and fixed too.
Matthew Dillon wrote:
>
> :
> :Matthew Dillon wrote:
> :[..]
> :> And, in anycase, I am not going to spend hours putting together a long
> :> involved patc
> This is unwontedly personal and has no place in a public mailing list.
> Please keep your replies confined to technical content (or your
> concerns about the lack thereof) and keep always in mind that getting
> emotional serves only to generate heat when what's needed is light.
>
> - Jordan
An
:
:Matthew Dillon wrote:
:[..]
:> And, in anycase, I am not going to spend hours putting together a long
:> involved patch when a simple short patch suffices. If you want to
:> spend the time to come up with your own patch (that doesn't screw the
:> pooch in regards to cluster p
Peter Wemm wrote:
> David Greenman wrote:
> >I've heard from both of you that you think the other is wrong. This isn'
t
> > very helpful, however, in finding the correct solution. What I'd like to he
ar
> > from both of you is the reasons why swap is better as a device, or not. The
It makes no sense whatsoever to spend hours or days reworking a major
subsystem *just* so the swap device can do without a dev_t. I don't
really give a damn about /dev/drum -- I said before and I will say again
that we can leave it out. But we need to give the swap device its's
de
> Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not
> reply to any of my postings. Not a single one, because I am wholely
> sick and tired of your superiority complex. This thread was not meant
This is unwontedly personal and has no place in a public mailing list.
In message <[EMAIL PROTECTED]>, David Greenman writes:
>There
>seems to be some unstated architectural philosophy that needs to be stated
>before any informed decision can be made about what is the right direction to
>go in.
The underlying problem is of course that struct buf is a conglomerate
o
:
: I've heard from both of you that you think the other is wrong. This isn't
:very helpful, however, in finding the correct solution. What I'd like to hear
:from both of you is the reasons why swap is better as a device, or not. There
:seems to be some unstated architectural philosophy that ne
David Greenman wrote:
>I've heard from both of you that you think the other is wrong. This isn't
> very helpful, however, in finding the correct solution. What I'd like to hear
> from both of you is the reasons why swap is better as a device, or not. There
> seems to be some unstated architect
Matthew Dillon wrote:
[..]
> And, in anycase, I am not going to spend hours putting together a long
> involved patch when a simple short patch suffices. If you want to
> spend the time to come up with your own patch (that doesn't screw the
> pooch in regards to cluster performanc
I've heard from both of you that you think the other is wrong. This isn't
very helpful, however, in finding the correct solution. What I'd like to hear
from both of you is the reasons why swap is better as a device, or not. There
seems to be some unstated architectural philosophy that needs to
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>Sorry Poul, but you have no authority in this matter. All the statements
>you have made in the last hour simply point out, in very clear terms,
>that you don't know what you are talking about. Instead of simply
>admiting a
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>Huh? Look Poul, I don't know what your problem is but I'm through
:>playing around with you. You aren't making any sense and, frankly my
:>dear sir, the buffer cache, vm_pager interface, VN device, and
:>vm_pager_str
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>Huh? Look Poul, I don't know what your problem is but I'm through
>playing around with you. You aren't making any sense and, frankly my
>dear sir, the buffer cache, vm_pager interface, VN device, and
>vm_pager_strategy sub
:>:--
:>:Poul-Henning Kamp FreeBSD coreteam member
:>:[EMAIL PROTECTED] "Real hackers run -current on their laptop."
:>
:>Uh... no. The chain buffer routines are supposed to be generic. In fact,
:>all the filesystem buffer cache I/O routines are supposed to be g
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:
>:Ahh, I see the mistake.
>:
>:All you need to fix this is to add a new function:
>:
>: void
>: flushswchainbuf(struct buf *nbp)
>: {
>: if (nbp->b_bcount) {
>: nbp->b_bufsize = nbp->b_bcount
:
:
:Ahh, I see the mistake.
:
:All you need to fix this is to add a new function:
:
: void
: flushswchainbuf(struct buf *nbp)
: {
: if (nbp->b_bcount) {
: nbp->b_bufsize = nbp->b_bcount;
: if ((nbp->b_flags & B_READ) ==
Ahh, I see the mistake.
All you need to fix this is to add a new function:
void
flushswchainbuf(struct buf *nbp)
{
if (nbp->b_bcount) {
nbp->b_bufsize = nbp->b_bcount;
if ((nbp->b_flags & B_READ) == 0)
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>First, you are confusing the underlying swap devices that we swapon on
:>with the parent swap device that controls them. The parent swap device
:>needs to have a dev_t - it does not currently have one, and this is
:>the e
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>First, you are confusing the underlying swap devices that we swapon on
>with the parent swap device that controls them. The parent swap device
>needs to have a dev_t - it does not currently have one, and this is
>the entry p
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>VN calls vm_pager_strategy() which collects I/O in filesystem buffers
:>(bp)'s in order to cluster the I/O, and you cannot initiate I/O on
:>filesystem buffers without a valid b_dev.
:>
:>So, the jist of the problem is t
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>VN calls vm_pager_strategy() which collects I/O in filesystem buffers
>(bp)'s in order to cluster the I/O, and you cannot initiate I/O on
>filesystem buffers without a valid b_dev.
>
>So, the jist of the problem is that in o
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>Sigh. Ok, I've fixed the VN device. Again. It looks like the removal of
:>/dev/drum removed a little too much. We need the device infrastructure
:>to support the VN device's use of swap backing store.
:>
:>This patc
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>Sigh. Ok, I've fixed the VN device. Again. It looks like the removal of
>/dev/drum removed a little too much. We need the device infrastructure
>to support the VN device's use of swap backing store.
>
>This patch below is
Sigh. Ok, I've fixed the VN device. Again. It looks like the removal of
/dev/drum removed a little too much. We need the device infrastructure
to support the VN device's use of swap backing store.
This patch below is a commit candidate. It could use a review, then I'll
co
27 matches
Mail list logo
