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
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 chance to hit
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
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,
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
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 chance to hit
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,
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 lru
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
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 hope
10 matches
Mail list logo
