From: chrisl@vmware.com
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrew Morton <akpm@digeo.com>,
linux-kernel@vger.kernel.org, chrisl@gnuchina.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: writepage return value check in vmscan.c
Date: Mon, 28 Oct 2002 11:58:31 -0800 [thread overview]
Message-ID: <20021028195831.GC1564@vmware.com> (raw)
In-Reply-To: <20021024183327.GS3354@dualathlon.random>
Hi Andrea,
On Thu, Oct 24, 2002 at 08:33:27PM +0200, Andrea Arcangeli wrote:
> >
> > That is exactly the case for vmware ram file. VMware only use it to share
> > memory. Those are the virtual machine's memory. We don't want to write
> > it back to disk and we don't care what is left on the file system because
> > when vmware exit, we will throw the guest ram data away just like a real
> > machine power off ram will lost. We are not talking about machine using
> > flash ram :-).
> >
> > It is kswapd try to flush the data and it should take response to handle
> > the error. If it fail, one thing it should do is keep the page dirty
> > if write back fail. At least not corrupt memory like that.
> >
> > If we can deliver the error to user program that would be a plus.
> > But this need to be fix frist.
>
> as said this cannot be fixed easily in kernel, or it would be trivial to
> lockup a machine by filling the fs changing the i_size of a file and by
> marking all ram in the machine dirty in the hole, the vm must be allowed
> to discard those pages and invaliding those posted writes. At least
> until a true solution will be available you should change vmware to
> preallocate the file, then it will work fine because you will catch the
> ENOSPC error during the preallocation. If you work on shmfs that will be
> very quick indeed.
I still think throwing process's page away if write fail is bad.
If kernel drop the data, that process is not able to run correctly
anyway. Why not keep the page here and let oom killer to pick up the
process to kill. In this way, we at least have some process able to run
correctly instead of every process which hit the out of disk space has
some bad data.
Cheers
Chris
next prev parent reply other threads:[~2002-10-28 19:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-24 8:25 writepage return value check in vmscan.c chrisl
2002-10-24 8:36 ` Andrew Morton
2002-10-24 9:15 ` Alan Cox
2002-10-24 11:44 ` Andrea Arcangeli
2002-10-24 16:12 ` Andrew Morton
2002-10-24 17:59 ` chrisl
2002-10-24 11:31 ` Andrea Arcangeli
2002-10-24 18:30 ` chrisl
2002-10-24 18:40 ` Andrea Arcangeli
2002-10-24 19:14 ` Rik van Riel
2002-10-24 19:25 ` Andrew Morton
2002-10-24 17:57 ` chrisl
2002-10-24 18:33 ` Andrea Arcangeli
2002-10-24 19:15 ` chrisl
2002-10-24 20:41 ` Andrea Arcangeli
2002-10-24 21:17 ` chrisl
2002-10-24 20:46 ` Andrew Morton
2002-10-24 21:23 ` chrisl
2002-10-24 21:29 ` Andrew Morton
2002-10-25 16:11 ` Paul Larson
2002-10-25 16:31 ` Christoph Hellwig
2002-10-25 17:07 ` Rik van Riel
2002-10-25 18:44 ` Andrew Morton
2002-10-28 19:17 ` chrisl
2002-10-28 19:53 ` Andrew Morton
2002-10-28 20:38 ` chrisl
2002-10-28 21:14 ` Andrea Arcangeli
2002-10-28 8:28 ` Christoph Rohland
2002-10-28 18:44 ` chrisl
2002-10-28 19:22 ` Andrea Arcangeli
2002-10-28 19:29 ` chrisl
2002-10-29 6:10 ` Randy.Dunlap
2002-10-29 7:08 ` Andreas Dilger
2002-10-28 19:58 ` chrisl [this message]
2002-10-28 21:32 ` Andrea Arcangeli
2002-10-30 4:13 ` chrisl
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=20021028195831.GC1564@vmware.com \
--to=chrisl@vmware.com \
--cc=akpm@digeo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrea@suse.de \
--cc=chrisl@gnuchina.org \
--cc=linux-kernel@vger.kernel.org \
/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).