On 9/3/00, 3:20:01 AM, Alexander Viro <[EMAIL PROTECTED]> wrote regarding
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM now?:
> On Sat, 2 Sep 2000, Linus Torvalds wrote:
> > Not at all. In fact, I'd prefer it that way, because this same thing is
> > obviously going to be
On Sun, 3 Sep 2000, Rik van Riel wrote:
> On Sun, 3 Sep 2000, Linus Torvalds wrote:
> >
> > What you're saying is that you're ignoring the evidence because you don't
> > like it and you don't understand how it happens.
> >
> > The BUG() was "impossible", so you're discounting it?
> >
> > I c
On Sun, 3 Sep 2000, Linus Torvalds wrote:
> On Sun, 3 Sep 2000, Rik van Riel wrote:
> > > Rik.
> > >
> > > You're apparently completely ignoring the fact that the page
> > > "already on the LRU queue" was just allocated from
> > > __alloc_pages() in the backtrace you had.
> >
> > It wasn't. If i
On Sun, 3 Sep 2000, Rik van Riel wrote:
> > Rik.
> >
> > You're apparently completely ignoring the fact that the page
> > "already on the LRU queue" was just allocated from
> > __alloc_pages() in the backtrace you had.
>
> It wasn't. If it was allocated there, the boobytraps in
> either rmqueu
On Sun, 3 Sep 2000, Linus Torvalds wrote:
> On Sun, 3 Sep 2000, Rik van Riel wrote:
> > >
> > > I'd like to know what it was. Last I heard, it was still the
> > > case of "pages just off the freelist had some bits set that they
> > > shouldn't have". That makes me nervous.
> >
> > Nope, that was
On Sun, 3 Sep 2000, Rik van Riel wrote:
> >
> > I'd like to know what it was. Last I heard, it was still the
> > case of "pages just off the freelist had some bits set that they
> > shouldn't have". That makes me nervous.
>
> Nope, that was what you /thought/ it was.
Rik.
You're apparently c
On Sun, 3 Sep 2000, Rik van Riel wrote:
> On Sat, 2 Sep 2000, Linus Torvalds wrote:
> > On Sat, 2 Sep 2000, Rik van Riel wrote:
>
> > > 1) the innd data corruption bug
> >
> > This, I think, was due to a bug in ext2 truncate. If so, it
> > should be fixed in test8-pre2.
>
> Cool...
Unfortun
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> On Sat, 2 Sep 2000, Rik van Riel wrote:
> > 1) the innd data corruption bug
>
> This, I think, was due to a bug in ext2 truncate. If so, it
> should be fixed in test8-pre2.
Cool...
> > 2) system hangs with 0 free low memory and some free
> >high
On Sun, 3 Sep 2000, Alexander Viro wrote:
> OK, after a bit of thinking it looks like we'll need slightly different
> prototype. How about the following? BTW, mem_is_zero() really asks for
> inclusion into string.h, IMO.
Arrgh. Sorry about that mess. Corrected variant:
diff -urN rc8-2/fs/buf
Hi !
I've read the discussion about the truncate() problem and tried to
understand ;) However, there's somethign I don't catch in your code (typo
? bug ? misunderstanding on my side ?)
Linus wrote:
There's a really simple way to avoid this: compare the thing you're going
to zero out against zer
On Sun, 3 Sep 2000, [iso-8859-1] Henrik Størner wrote:
> On Sat, Sep 02, 2000 at 01:58:58PM -0700, Linus Torvalds wrote:
>
> [ext2 truncate bug which caused the innd file corruption may
> also affect other filesystems]
>
> > Anyway, the way to test if you have the bug is this simple program
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> Not at all. In fact, I'd prefer it that way, because this same thing is
> obviously going to be useful for any other block filesystem with the same
> issue.
Which is a nice way to say "any other block filesystem in the tree" ;-/
Oh, well... Modulo ->
On Sat, 2 Sep 2000, Linus Torvalds wrote:
>
>
> On Sun, 3 Sep 2000, Alexander Viro wrote:
> > >
> > > Comments? Basically the "grab_cache_page()" would be a "read_cache_page()"
> > > instead with all the wait-on-page etc stuff.
> >
> > Works for me. However, that way it looks like a fs/buf
On Sun, 3 Sep 2000, Alexander Viro wrote:
> >
> > Comments? Basically the "grab_cache_page()" would be a "read_cache_page()"
> > instead with all the wait-on-page etc stuff.
>
> Works for me. However, that way it looks like a fs/buffer.c fodder.
> Mind if I just call it block_zero_page(page, f
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> You don't actually have to be smart.
>
> There's a really simple way to avoid this: compare the thing you're going
> to zero out against zero before you memset() it to zero. If it was already
> zero, you just unlock the page and release.
>
> Downsi
On Sat, 2 Sep 2000, Alexander Viro wrote:
> +
> + /*
> + * So truncate in the middle of a hole not on a block boundary will
> + * allocate a block. BFD. Everything is still consistent, so trying
> + * to be smart is not worth the trouble.
> + */
You don't actually have t
On Sat, 2 Sep 2000, Alexander Viro wrote:
> IOW, bug in question _does_ give the same kind of behaviour, but whether
> innd is hitting it or something different that happens to act like that...
> The only way to know is to try it.
>
> I'll send rediffed patch in half an hour.
All right, it t
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> > 1) the innd data corruption bug
>
> This, I think, was due to a bug in ext2 truncate. If so, it should be
> fixed in test8-pre2.
Ted had ACKed the previous chunk of truncate changes, so that one will go
immediately once the -pre2 is on ftp.kernel
On Sat, 2 Sep 2000, Rik van Riel wrote:
>
> In fact, I plan to spend most of my time trying to track down
> the 2 VM problems on tytso's list:
>
> 1) the innd data corruption bug
This, I think, was due to a bug in ext2 truncate. If so, it should be
fixed in test8-pre2.
Al, I think you said y
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> On Sat, 2 Sep 2000, Rik van Riel wrote:
> >
> > Not really. I'm not aware of any bug with my VM that doesn't
> > occur in the standard VM too.
>
> So what happened with the BUG() thing that you had? I never saw
> any resolution to that, and that certai
On Sat, 2 Sep 2000, Rik van Riel wrote:
>
> Not really. I'm not aware of any bug with my VM that doesn't
> occur in the standard VM too.
So what happened with the BUG() thing that you had? I never saw any
resolution to that, and that certainly didn't happen with the standard VM.
On Sat, 2 Sep 2000, bert hubert wrote:
> On Fri, Sep 01, 2000 at 03:58:22PM -0300, Rik van Riel wrote:
>
> > > filesystem? It starts swapping like mad and generally behaves
> > > indecently, despite the huge 1024M of RAM it has.
> >
> > http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
> >
> >
22 matches
Mail list logo
