Alexander Viro wrote:
>
> On Sun, 3 Dec 2000, Linus Torvalds wrote:
>
> >
> > Synching up with Alan and various other stuff. The most important one
> > being the fix to the inode dirty block list.
>
> It doesn't solve the problem. If you unlink a file with dirty metadata
> you have a nice chanc
On Mon, 4 Dec 2000, Linus Torvalds wrote:
> I just wanted to be clear on the purpose of the patches. The bforget() one
> looks like "taking care of the details", but not like a bug-fix. Agreed?
Agreed - invalidate_inode_buffers() seems to be doing the right thing,
so previous objections do not
[Mohammad A. Haque]
> Cool. Anyone have have a unified patch against pre4 or should I start
> digging through my mail? =)
test12pre5, I guess.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http
On Mon, 4 Dec 2000, Alexander Viro wrote:
>
> Well, to start with you don't want random bh's floating around on the
> inode's list. With the current code truncate()+fsync() can send a lot
> of already freed stuff to disk. Even though we can survive that (making
> clear_inode() to get rid of the
On Mon, 4 Dec 2000, Linus Torvalds wrote:
>
>
> On Tue, 5 Dec 2000, Andrew Morton wrote:
> >
> > - test12-pre4
> > - aviro bforget patch
>
> Is the bforget patch really needed?
>
> If clear_inode() gets rid of dirty buffers, I don't see how new dirty
> buffers can magically appear
Cool. Anyone have have a unified patch against pre4 or should I start
digging through my mail? =)
Andrew Morton wrote:
> This is with
>
> - test12-pre4
> - aviro bforget patch
> - UnlockPage() removed from vmscan.c:623
> - and
>
> --- linux-2.4.0-test12-pre4/fs/e
On Tue, 5 Dec 2000, Andrew Morton wrote:
>
> - test12-pre4
> - aviro bforget patch
Is the bforget patch really needed?
If clear_inode() gets rid of dirty buffers, I don't see how new dirty
buffers can magically appear. I may have missed part of the discussion on
all this.
I thin
Alexander Viro wrote:
>
> OK, guys, I think I've got it:
Yes, you have.
Two machines, four hours, zero failures.
This is with
- test12-pre4
- aviro bforget patch
- UnlockPage() removed from vmscan.c:623
- and
--- linux-2.4.0-test12-pre4/fs/ext2/inode
On Mon, 4 Dec 2000, Stephen C. Tweedie wrote:
> Agreed. However, is there any reason to have this as a separate
> function? bforget() should _always_ remove the buffer from any inode
> queue. You can make that operation conditional on (bh->b_inode !=
> NULL) if you want to avoid taking the l
On Mon, Dec 04, 2000 at 01:01:36AM -0500, Alexander Viro wrote:
>
> It doesn't solve the problem. If you unlink a file with dirty metadata
> you have a nice chance to hit the BUG() in inode.c:83. I hope that patch
> below closes all remaining holes. See analysis in previous posting
> (basically,
OK, guys, I think I've got it:
static int ext2_update_inode(struct inode * inode, int do_sync)
{
...
mark_buffer_dirty_inode(bh, inode);
...
}
Yes, that's right. bh of piece of inode table is put on inode's list.
Fix: in ext2/inode.c 1211s/mark_buffer_dirty_inode/
Alexander Viro wrote:
>
> On Sun, 3 Dec 2000, Linus Torvalds wrote:
>
> >
> > Synching up with Alan and various other stuff. The most important one
> > being the fix to the inode dirty block list.
>
> It doesn't solve the problem. If you unlink a file with dirty metadata
> you have a nice chanc
On Sun, 3 Dec 2000, Linus Torvalds wrote:
>
> Synching up with Alan and various other stuff. The most important one
> being the fix to the inode dirty block list.
It doesn't solve the problem. If you unlink a file with dirty metadata
you have a nice chance to hit the BUG() in inode.c:83. I ho
13 matches
Mail list logo
