linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Viro <viro@math.psu.edu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andrew Morton <andrewm@uow.edu.au>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] inode dirty blocks
Date: Mon, 4 Dec 2000 22:31:00 -0500 (EST)	[thread overview]
Message-ID: <Pine.GSO.4.21.0012042211310.7166-100000@weyl.math.psu.edu> (raw)
In-Reply-To: <Pine.LNX.4.10.10012041840240.1904-100000@penguin.transmeta.com>



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. I may have missed part of the discussion on
> all this.

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 list will save you from corruption)...
it doesn't look like a good idea.

BTW, in the current form clear_inode() doesn't get rid of the dirty
buffers. It misses the pages that became anonymous and it misses the
metadata that became freed. We can do that, but I'ld rather avoid
leaving these buffer_heads on the inode's list - stuff that got freed
has no business to be accessible from in-core inode.

> I think that the second patch from Al (the inode dirty meta-data) is the
> _real_ fix, and I don't see why the bforget changes should matter.

We can survive without them (modulo patch to clear_inode()), but...
BTW, there is another reason why we want to have separate function
for freeing the stuff: we may want to mark them clean. If they are
already under IO it will do nothing, but if they are merely dirty...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-12-05  4:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-04  2:29 test12-pre4 Linus Torvalds
2000-12-04  3:57 ` test12-pre4 Mohammad A. Haque
2000-12-04  8:03   ` test12-pre4 Jeff Garzik
2000-12-04 12:25     ` test12-pre4 Alan Cox
2000-12-04 12:21   ` test12-pre4 Alan Cox
2000-12-04 20:22     ` test12-pre4 Nikhil Goel
2000-12-04  6:01 ` [PATCH] inode dirty blocks test12-pre4 Alexander Viro
2000-12-04 13:25   ` Andrew Morton
2000-12-04 13:49     ` [PATCH] inode dirty blocks Alexander Viro
2000-12-05  1:47       ` Andrew Morton
2000-12-05  2:41         ` Linus Torvalds
2000-12-05  3:31           ` Alexander Viro [this message]
2000-12-05  3:52             ` Linus Torvalds
2000-12-05  4:19               ` Alexander Viro
2000-12-05  2:49         ` Mohammad A. Haque
2000-12-05  4:15           ` Peter Samuelson
2000-12-04 18:16   ` [PATCH] inode dirty blocks Re: test12-pre4 Stephen C. Tweedie
2000-12-04 19:54     ` Alexander Viro
2000-12-05 20:35   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.21.0012042211310.7166-100000@weyl.math.psu.edu \
    --to=viro@math.psu.edu \
    --cc=andrewm@uow.edu.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).